| 00:13.50 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 01:30.49 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 02:03.09 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 05:47.57 | *** join/#maemo-ssu amiconn (quassel@rockbox/developer/amiconn) |
| 06:28.41 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
| 07:18.22 | *** join/#maemo-ssu scoobertron (~tom@66.172.11.27) |
| 07:18.40 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 07:22.03 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 07:54.56 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 08:18.44 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 08:23.24 | freemangordon | Pali: any idea who loads hsi/ssi drivers? |
| 08:32.14 | *** join/#maemo-ssu oooaaaooo (~rootzilla@d122-109-58-186.per802.wa.optusnet.com.au) |
| 08:39.03 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 08:39.11 | oooaaaooo | hi guys what is the difference between stable & testing? |
| 09:17.53 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 09:20.36 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2B39B.dip0.t-ipconnect.de) |
| 09:25.17 | *** join/#maemo-ssu NIN102 (~NIN@p5DD2B39B.dip0.t-ipconnect.de) |
| 09:49.26 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 11:28.06 | DocScrutinizer05 | see /topic |
| 11:28.20 | DocScrutinizer05 | see http://wiki.maemo.org/Community_SSU |
| 11:40.08 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 11:57.55 | Pali | freemangordon: no |
| 12:05.59 | freemangordon | Pali: hmm, no matter what I do, there is no responce from cmt :( |
| 12:06.37 | freemangordon | it looks like cmt is not powered |
| 12:07.10 | freemangordon | Pali: did you ever got cmt drivers working with 3.x kernels? |
| 12:07.14 | freemangordon | *get |
| 12:07.36 | Pali | I think not, they not worked with 3.5 too |
| 12:08.05 | freemangordon | weird, Skry had them working |
| 12:08.24 | freemangordon | seems like the patches you've applied are not the correct ones |
| 12:09.05 | freemangordon | Pali: do you have a link to nemomobile kernel adaptation git tree? |
| 12:09.09 | freemangordon | for n900 that is |
| 12:09.13 | freemangordon | I cant find it |
| 12:09.37 | Pali | git://github.com/nemomobile/kernel-adaptation-n950-n9.git |
| 12:09.42 | Pali | git://gitorious.org/meego-device-adaptation/n900_kernel.git |
| 12:09.48 | Pali | git://github.com/skry/linux.git |
| 12:09.52 | Pali | git://github.com/skry/linux-n900.git |
| 12:10.09 | freemangordon | git://gitorious.org/meego-device-adaptation/n900_kernel.git gives 404 |
| 12:10.22 | Pali | I have these repos ^^^ |
| 12:10.31 | freemangordon | oh, this is git :D |
| 12:13.43 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 12:42.59 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 13:02.50 | *** join/#maemo-ssu T_X (~T_X@open-mesh.org) |
| 13:18.42 | *** join/#maemo-ssu arcean (~arcean@aacu151.neoplus.adsl.tpnet.pl) |
| 13:18.58 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 13:25.12 | *** join/#maemo-ssu arcean_ (~arcean@aacr134.neoplus.adsl.tpnet.pl) |
| 13:31.40 | freemangordon | Pali: why "CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set"? |
| 13:31.55 | freemangordon | I bet we work without L2 cache |
| 13:32.07 | Pali | do not know |
| 13:32.11 | freemangordon | :) |
| 13:32.35 | Pali | I tried to merge rx51_defconfig from maemo 2.6.28 kernel with omap2plus from 3.5 |
| 13:32.44 | freemangordon | ok |
| 13:32.47 | Pali | and result is rx51_defconfig in 3.10 |
| 13:32.54 | Pali | if there is something missing, enable it |
| 13:32.58 | freemangordon | ok |
| 13:33.09 | Pali | also I looked in menuconfig and tried to enable what is needed |
| 13:33.19 | Pali | but make menuconfig is really really really big |
| 13:33.30 | freemangordon | Pali: in ssi driver there is something missing, but I don;t know how to readd it using hwmod/clock framework |
| 13:33.48 | Pali | freemangordon: try to ask sre |
| 13:33.54 | Pali | he upstreaming now ssi driver |
| 13:34.02 | Pali | and do not know which version using... |
| 13:34.04 | freemangordon | it is a function disabling autoidle on dpll3 |
| 13:34.17 | freemangordon | O bet what he tries to upstream does not work |
| 13:34.20 | freemangordon | *I |
| 13:35.01 | Pali | https://lkml.org/lkml/2013/8/11/67 |
| 13:35.49 | Pali | he could be on #debian |
| 13:36.31 | freemangordon | Pali: seems there is some HW bug, see ssi_disable_dpll3_autoidle in meego tree |
| 13:36.40 | freemangordon | sre == Skry ? |
| 13:36.44 | Pali | no |
| 13:36.47 | freemangordon | oh |
| 13:37.05 | Pali | Sebastian Reichel |
| 13:37.20 | Pali | he porting debian to n900 |
| 13:37.28 | freemangordon | ok, will look at what he does |
| 13:40.08 | freemangordon | hmm seems different |
| 13:42.15 | Pali | freemangordon: maybe we should look at meego n900 kernel tree if there are not some needed patches |
| 13:42.36 | freemangordon | seems his driver is ported to hwmod |
| 13:45.19 | freemangordon | Pali: BTW CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is the same as my ppa api |
| 13:45.38 | freemangordon | I mean, it calls smc to save/restore AUX reg |
| 13:45.56 | freemangordon | without that AUX context get lost on sleep |
| 13:46.00 | freemangordon | afaik |
| 13:57.15 | Pali | freemangordon: look at commit 1a7e01f01a4af807206de0d26f059c3459f3a1fb in meego n900 git tree |
| 13:57.35 | Pali | it adding some regulator for camera operation |
| 13:58.04 | freemangordon | ok |
| 13:59.15 | Pali | and there is another commit cae12d3ebf22039cc7216f317bebac2f797d2a31 which reduce battery consumption |
| 14:00.35 | freemangordon | Pali: want to test sri's ssi driver first |
| 14:00.47 | Pali | there are maybe more interesting patches... |
| 14:00.55 | Pali | ok |
| 14:00.56 | freemangordon | :nod: |
| 14:14.52 | DocScrutinizer05 | honestly wonders what you guys are targeting at |
| 14:15.15 | freemangordon | 3.x working with maemo? |
| 14:15.24 | DocScrutinizer05 | looks like, yeah |
| 14:15.54 | DocScrutinizer05 | "working" and *working* are two different things though |
| 14:16.36 | freemangordon | if we can't make it on n900, we aon;t be able to do it on neo900 as well |
| 14:16.41 | freemangordon | *can't |
| 14:17.09 | DocScrutinizer05 | maybe that whole effort turn out to be futile in the end - see my recent rant why you frequently regularly want to or even have to "fork" and run your own kernel flavor for embedded |
| 14:17.32 | freemangordon | DocScrutinizer05: yep, but lets see what we can do with upstream first |
| 14:17.39 | DocScrutinizer05 | sure |
| 14:17.42 | DocScrutinizer05 | :-) |
| 14:17.44 | freemangordon | before doing forks :) |
| 14:18.16 | DocScrutinizer05 | after all you *should* be able to forward-port _all_ the nice powermanagement patches that we find in maemo kernel |
| 14:18.24 | freemangordon | :nod: |
| 14:18.37 | freemangordon | BTW I think part of them are already upstreamed |
| 14:18.47 | freemangordon | but don;t ask me which prts :D |
| 14:18.54 | *** join/#maemo-ssu FlameReaper (~assassin@175.139.222.7) |
| 14:18.54 | DocScrutinizer05 | if the result will go upstream ever that's another question |
| 14:18.59 | freemangordon | sure |
| 14:19.29 | DocScrutinizer05 | but we should be able to get a recent kernel with powersaving as good as maemo 1.6.28 |
| 14:19.39 | DocScrutinizer05 | 2.6.... |
| 14:19.43 | DocScrutinizer05 | typo |
| 14:20.25 | DocScrutinizer05 | then also revert all the damage done to sysfs etc by kernel devels ;-) Done |
| 14:21.03 | freemangordon | Pali: re camera - we already have that regulator, but board code is missing the ".supply = "vaux2" part |
| 14:21.08 | freemangordon | NFC if that matters |
| 14:21.44 | DocScrutinizer05 | in the end it doesn't matter if you backport 80 patches into KP57 or forward port 150 Nokia patches and rollbacks to linus kernel 3.11 |
| 14:21.57 | DocScrutinizer05 | the result in the end should be identical |
| 14:22.13 | freemangordon | sure |
| 14:22.27 | freemangordon | the easy way is to use KP :) |
| 14:22.36 | *** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
| 14:23.10 | freemangordon | but we rather keep that as a fallback |
| 14:23.18 | DocScrutinizer05 | I strongly support any such project you're doing. It helps us acquire better knowledge about our kernel |
| 14:23.54 | DocScrutinizer05 | and in the end both approaches will result in same final "product" |
| 14:24.12 | DocScrutinizer05 | when done correctly and comprehensive |
| 14:24.25 | freemangordon | sure, but having upstream kernel working is preferable imo |
| 14:24.42 | freemangordon | we can use it for other distros as well |
| 14:25.40 | DocScrutinizer05 | as already explained. The 100% finalized result is identical for both approaches. It's the different flaws you get for 99% finalized versions that makes the difference |
| 14:26.43 | DocScrutinizer05 | for the KP approach you will miss functions or see broken functions that are new to 3.11. For the linus branch aproach you will see flawed power management |
| 14:27.23 | DocScrutinizer05 | after fixing those flaws, both end results are 100% identical |
| 14:30.01 | DocScrutinizer05 | you definitely can use stock maemo kernel for other distros as well. See easydeb |
| 14:30.40 | DocScrutinizer05 | the question is what's the effort to port any such kernel to other hw platforms |
| 14:30.46 | DocScrutinizer05 | and keep it up to date |
| 14:31.08 | DocScrutinizer05 | for both the linusbranch approach has clear advantages |
| 14:31.52 | DocScrutinizer05 | for maemo stability at large, the KP approach is clearly the better one |
| 14:33.33 | DocScrutinizer05 | I'm just a tiny bit worried that users might think this project is closely related to CSSU which clearly it isn't and shouldn't |
| 14:34.26 | DocScrutinizer05 | we maybe need to mint a new term, like e.g. CSSU-Factory |
| 14:34.52 | DocScrutinizer05 | or CSSU-Lab |
| 14:35.52 | DocScrutinizer05 | would make a nice home for FPTF as well |
| 14:36.35 | DocScrutinizer05 | in the end Neo900 maemo will be a "new distro" no matter how binary compatible it might be for apps |
| 14:36.55 | DocScrutinizer05 | CSSU-S/T clearly is NO new distro |
| 14:37.14 | DocScrutinizer05 | a common misconception |
| 14:38.31 | DocScrutinizer05 | introducing a new noticeably different (on API/revision level) kernel pretty much qualifies for "new distro" |
| 14:40.31 | *** join/#maemo-ssu hatake_kakashi (~no@unaffiliated/tuxsavvy) |
| 14:46.17 | freemangordon | Pali: hmm, sri's driver makes no difference :( |
| 14:47.14 | DocScrutinizer05 | maybe you want to check e.g SHR, it has working BB5 modem on N900 |
| 14:47.41 | DocScrutinizer05 | ask dos1 |
| 14:47.43 | freemangordon | any link to kernel tree? |
| 14:47.47 | freemangordon | ok |
| 14:47.59 | Sicelo | who's sri? |
| 14:48.10 | DocScrutinizer05 | sre |
| 14:48.14 | Sicelo | ok. |
| 14:48.24 | Pali | sre = Sebastian Reichel |
| 14:48.47 | Pali | working with debian on n900 |
| 14:48.53 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 14:48.53 | freemangordon | hmm, he is not on #debian |
| 14:48.55 | Sicelo | he's not done with the modem driver yet. |
| 14:49.16 | Sicelo | quickest way to get him is Jabber |
| 14:49.34 | DocScrutinizer05 | ~shr |
| 14:49.35 | infobot | i heard shr is The Stable Hybrid Release (SHR), intended to be a community driven distribution composed of the FSO and some basic applications, that can be configured to use several different graphical toolkits, for example GTK or EFL. SHR is based on the FSO build. At first, SHR was introduced in order to use the Openmoko2007.2 GTK software in combination with the new FSO, but things have changed. |
| 14:49.48 | Sicelo | dunno why, but he's been mia on IRC for a while now |
| 14:49.53 | Pali | freemangordon: sre has wireshark plugin for isi: http://sre.ring0.de/ |
| 14:50.01 | Pali | maybe it can be used for debugging |
| 14:50.37 | freemangordon | Pali: we are far from this ste, the modem seems to be either powered off or with no clk |
| 14:50.42 | freemangordon | *step |
| 14:51.04 | Sicelo | that's why he needed a serial adapter :P |
| 14:51.08 | DocScrutinizer05 | http://shr-project.org/trac |
| 14:51.28 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.256744] SSI protocol aka McSAAB added |
| 14:51.30 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.291198] cmt_speech cmt_speech: hsi_client_probe |
| 14:51.32 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.331665] ssi_protocol ssi_protocol: Configuring SSI port |
| 14:51.34 | Pali | freemangordon: look at sre kernel tree: http://sre.ring0.de/linux/ |
| 14:51.34 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.331787] ssi_protocol ssi_protocol: Issuing BOOT INFO REQ command |
| 14:51.36 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.331817] hsi_async 346 |
| 14:51.38 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.337951] ssi_protocol ssi_protocol: Issuing RX command |
| 14:51.41 | freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.337982] hsi_async 346 |
| 14:51.42 | DocScrutinizer05 | Pali: II have ISI plugin for wireshark ;-) |
| 14:52.17 | freemangordon | Pali: and ^^^ is all I have, modem does not respond to "BOOT INFO REQ" |
| 14:53.10 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?p=1022444#post1022444 |
| 14:53.13 | DocScrutinizer05 | ;-D |
| 14:56.07 | DocScrutinizer05 | freemangordon: NB the cmt_speech is a upper layer that uses a virtual channel in the low level ISI interface to BB5 |
| 14:56.47 | DocScrutinizer05 | before even bothering about cmt_speech, you should get basic communication to BB5 working |
| 14:56.57 | freemangordon | :nod: |
| 14:57.30 | DocScrutinizer05 | ISI is a bitch |
| 14:57.56 | Pali | freemangordon: https://elektranox.org/n900/contact.html |
| 14:58.29 | DocScrutinizer05 | iirc you need a quite complicated strictly defined sequence of actions to crank it up |
| 14:58.54 | DocScrutinizer05 | worse than e.g. USB |
| 14:59.06 | freemangordon | DocScrutinizer05: yep, by using gpio pins |
| 14:59.22 | DocScrutinizer05 | not only, that's actually not even ISI |
| 14:59.31 | DocScrutinizer05 | ISI is a "network protocol" |
| 14:59.35 | dos1 | SHR on N900 is using 2.6.37 |
| 14:59.38 | DocScrutinizer05 | similar to TCP/IP |
| 14:59.40 | freemangordon | to power the modem up that is |
| 14:59.51 | dos1 | recipe is named "linux-nokia900-meego" |
| 14:59.52 | freemangordon | dos1: oh, pretty old I'd say :) |
| 15:00.12 | dos1 | yup |
| 15:00.27 | freemangordon | modem was working there |
| 15:00.32 | dos1 | development pretty much stalled after some initial work |
| 15:00.43 | dos1 | so it probably won't be useful |
| 15:01.23 | Pali | freemangordon: he is probably under irc name elektranox |
| 15:01.29 | DocScrutinizer05 | it's at least nit like "power up cmt, send AT, receive OK" |
| 15:01.32 | DocScrutinizer05 | not* |
| 15:01.46 | DocScrutinizer05 | you need to *establish* the connection |
| 15:01.51 | freemangordon | Pali: hmm, lemme try to reach him |
| 15:02.56 | Sicelo | his nick was just 'sre' when he was still available. xmpp is the quickest way as mentioned above |
| 15:02.56 | DocScrutinizer05 | >SSI protocol aka McSAAB added< and immediately then >cmt_speech cmt_speech: hsi_client_probe< looks completely odd and fishy anyway |
| 15:03.17 | DocScrutinizer05 | cmt_speech CANNOT work immediately after adding the low level PHY driver |
| 15:03.19 | freemangordon | yep, seems like function calls were wrong |
| 15:04.44 | freemangordon | DocScrutinizer05: though that should not prevent from communication with the modem |
| 15:07.25 | Pali | look at /msg NickServ info elektranox |
| 15:08.35 | Sicelo | ah, freenode.. :) |
| 15:08.52 | freemangordon | <PROTECTED> |
| 15:09.04 | Sicelo | i used to find him on OFTC |
| 15:09.23 | Pali | really above is his irc freenode nick |
| 15:09.31 | freemangordon | :nod: |
| 15:09.41 | Pali | use xmpp or email |
| 15:09.47 | Pali | now he is offline |
| 15:10.58 | Sicelo | on xmpp he's right now online, but marked DND. around UTC 1800, he's usually online |
| 15:11.22 | DocScrutinizer05 | freemangordon: cmt_speech is similar to a USB soundcard driver. HSI is similar to PCI where a NIC is plugged in. ISI is similar to the TCP stack, and your "soundcard" you want to talk to via cmt_speech would be attached via USB-over-TCP/IP |
| 15:11.49 | freemangordon | DocScrutinizer05: I understand that :) |
| 15:14.01 | DocScrutinizer05 | :-) |
| 15:14.13 | freemangordon | Pali: http://sre.ring0.de/linux/log/?h=ssi-cleaned-dt |
| 15:14.29 | freemangordon | I guess we shall wait for that to go upstream :) |
| 15:15.18 | DocScrutinizer05 | fsck DT |
| 15:15.25 | freemangordon | yeah :( |
| 15:15.30 | DocScrutinizer05 | another kernel devs' brainfart, eh? |
| 15:16.41 | Sicelo | but the linux-arm ML is clearly biased towards DT now.. looks like they just dismiss anything not DT |
| 15:17.29 | DocScrutinizer05 | feels like kernel devels invented a general way to describe arbitrarly shaped areas that are hw paltforms, but in RL hw platforms are not areas but 3D objects like irregular toroids etc |
| 15:18.41 | DocScrutinizer05 | some might even be higher-dimensional |
| 15:19.09 | DocScrutinizer05 | good luck for describing this via polygons |
| 15:19.59 | Sicelo | they'll tell you that gfx cards do that :p |
| 15:21.29 | DocScrutinizer05 | they will suffer a terrible mistake then, sinc graca only produce 2D projections of the real worls |
| 15:21.47 | DocScrutinizer05 | world even |
| 15:23.43 | DocScrutinizer05 | a pixmap is elementarily incapable to describe 3D objects comprehensively, and likewise it seems to me DT is incapable of describing real hw platforms in a sufficiently flexible manner |
| 15:24.13 | Sicelo | anyway, /me doesn't know sh*t about kernel development lol, just that i have had a chance to talk to people like sre before |
| 15:25.13 | jonwil | bah, my N900 work is getting me nowhere. Need to find something useful to do... |
| 15:32.43 | DocScrutinizer05 | well, I've seen kernel concepts come and go. And I guess DT is not one of the concepts here to stay |
| 15:35.16 | jonwil | what exactly is DT? |
| 15:35.19 | DocScrutinizer05 | just like maemo got rid of initrd, since initrd is nonsense for a highly specialized kernel meant to run on one well defined and immutable platform only |
| 15:36.32 | DocScrutinizer05 | jonwil: Device Tree. a description of *all* the hardware you find on the platform, incl all its properties |
| 15:37.22 | DocScrutinizer05 | drivers know sh*t about how to handle that particular platform, they look into DT to decide what to do. Basically |
| 15:37.38 | DocScrutinizer05 | bbl |
| 15:37.51 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 15:39.26 | DocScrutinizer05 | "which powersupply to ramp up to power that WLAN module?" -> "look into DT" |
| 15:40.22 | DocScrutinizer05 | "which interface to use to talk to the power supply to tell it to ramp-up?" -> "look into DT" |
| 15:40.39 | DocScrutinizer05 | aiui |
| 15:40.49 | jonwil | I can see now why its not so good for all platforms |
| 15:41.09 | jonwil | where its incapable of describing all the things you need to describe |
| 15:41.17 | DocScrutinizer05 | it's an idiotic idea in some cases |
| 15:41.29 | DocScrutinizer05 | yes, exactly |
| 15:41.40 | jonwil | if its idiotic, why do kernel devs want to persist with it? |
| 15:42.29 | DocScrutinizer05 | because it's so... computer-scientific |
| 15:42.51 | DocScrutinizer05 | BBLFRN |
| 15:42.54 | DocScrutinizer05 | o/ |
| 15:43.32 | *** join/#maemo-ssu FlameReaper (~assassin@183.171.169.9) |
| 15:44.11 | jonwil | If I had a dollar for every time I heard of a programmer continuing to persist with stupid code and continuing to not accept better ways of doing things, I would probably have enough money that I wouldn't need to write code for a living and could just retire... :P |
| 15:44.26 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 15:44.32 | Pali | DocScrutinizer05: DT is bettern then ACPI DSDT |
| 15:44.52 | jonwil | GOOD programmers will listen when someone says "I have a better way to do xyz" |
| 15:45.28 | Pali | ACPI is undebugable and unparsable |
| 15:45.35 | Pali | and human unreadable |
| 15:45.49 | Pali | and even worse machine not executable... |
| 15:45.58 | Pali | and needs own VM |
| 15:46.08 | Pali | and acpica in kernel! |
| 15:46.37 | Pali | and thanks to MS who created proprietary extension WMI which is now used for evryething |
| 15:46.50 | jonwil | Good luck getting ACPI working unless you reverse engineer Windows and do EXACTLY what Windows does (since that's all most motherboard vendors test against) |
| 15:46.59 | ShadowJK | A lot of the bugs come from the code assuming the OS will do X, and not checking if OS did X |
| 15:47.02 | Pali | thank you, rather DT |
| 15:47.09 | ShadowJK | yeah what jonwil said :) |
| 15:47.45 | ShadowJK | acpi is otherwise a cool idea, replacing BIOS roms running real mode code with a portable bytecode |
| 15:48.37 | Pali | portable bytecode? really? it is bytecode designed for x86 |
| 15:49.38 | Pali | I'm not able to decompile my DSDT because it has invalid sequences... |
| 15:49.50 | Pali | and ability to patch it is not possible |
| 15:50.19 | ShadowJK | Kernel patches it all the time :-) |
| 15:50.22 | jonwil | is there a better way to do the kind of stuff embedded ARM needs than DT? |
| 16:05.47 | DocScrutinizer51 | FFS, queue at the voting booths :-( |
| 16:06.09 | DocScrutinizer51 | ~xyawn |
| 16:06.09 | infobot | good coffee |
| 16:06.24 | DocScrutinizer51 | where? |
| 16:22.52 | DocScrutinizer05 | well, ACPI never *really* worked for me and my linux boxen |
| 16:23.36 | DocScrutinizer05 | since ACPI is not one of the selling points you check when picking a MoBo |
| 16:24.17 | DocScrutinizer05 | thus vendors do whatever shite, as long as it works with windows (like jonwil said) |
| 16:24.47 | DocScrutinizer05 | industry level PCs are a tad fifferent I guess |
| 16:24.52 | DocScrutinizer05 | different even |
| 16:41.03 | DocScrutinizer05 | in the end DT and ACPI are a good thing for general purpose one-kernel-fits-all approach that is used for x86 PC. For a highly tailored-to-fit "custom" kernel designed to perform as good as possible on one particular embeeded device like N900, you better forget about any such concept all together |
| 16:41.55 | DocScrutinizer05 | s/eede/edde/ |
| 16:45.41 | DocScrutinizer05 | really, shoehorning a concept like ACPI (or DT?) onto a device that doesn't even have any BIOS to support the idea's founding requirements - that feels more than silly to me |
| 16:50.34 | DocScrutinizer05 | "first let's ponder how to hardcode a ACPI emulator into the kernel to compensate for missing BIOS with real DSDT/ACPI tables. Then we try to figure how we can read out that crap and nevertheless *despite* of it do the right thing for our particular platform, for which we need custom patches to 50% of device drivers anyway and those patches will never make it upstream" - outright ridiculous |
| 16:52.59 | DocScrutinizer05 | that's the moment when you want to "fork" |
| 16:53.29 | DocScrutinizer05 | which so far every single embedded project I know of eventually did |
| 16:53.37 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 16:54.09 | DocScrutinizer05 | maybe they don't call it "fork" |
| 16:54.38 | DocScrutinizer05 | but in the end it is. Just a highly customized kernel (and userland) that has no chances to go upstream |
| 16:55.48 | DocScrutinizer05 | upstream is PC centric, and it gets more and more PC centric every day dudes like Poettering rush over it |
| 16:58.44 | DocScrutinizer05 | systemd My ASS. Definitely the ideal concept for embedded |
| 17:00.13 | ShadowJK | just setup a board with 64M ram and systemd :) |
| 17:00.17 | DocScrutinizer05 | and android madness bleeding into linux recently doesn't help either |
| 17:00.58 | DocScrutinizer05 | newsflash time |
| 17:01.01 | DocScrutinizer05 | o/ |
| 17:01.10 | dos1 | what makes systemd so unsuited for embedded? |
| 17:03.30 | DocScrutinizer05 | the overhead |
| 17:03.50 | DocScrutinizer05 | or let me put it this way: the philosophy behind it |
| 17:04.30 | DocScrutinizer05 | systemd makes /usr mandatory during *early* boot |
| 17:04.38 | DocScrutinizer05 | actually it abolishes /usr |
| 17:04.56 | DocScrutinizer05 | it also abolishes udev |
| 17:05.23 | DocScrutinizer05 | but not to replace it by sth more lightweight |
| 17:06.50 | DocScrutinizer05 | HECK, systemd *needs* d-bus last I tried to check |
| 17:07.09 | nedko | systemd works in pair with udev |
| 17:07.17 | DocScrutinizer05 | and don't get me started on d-bus |
| 17:07.22 | dos1 | hehe |
| 17:07.24 | nedko | :) |
| 17:07.45 | wmarone_ | AF_DBUS |
| 17:07.58 | nedko | wmarone_: it is in mainline? |
| 17:08.08 | wmarone_ | Haven't looked into it in a while |
| 17:09.18 | nedko | DocScrutinizer05: in fact systemd and udev are quite coupled. what they abolish is hal |
| 17:10.08 | DocScrutinizer05 | last I checked systemd simply scooped up and abolished udev |
| 17:11.07 | DocScrutinizer05 | but I know of embedded systems that opted out from udev in favour for sth more lightweight |
| 17:11.31 | DocScrutinizer05 | I don't see how that goes along with systemd |
| 17:12.07 | DocScrutinizer05 | I also know of embedded systems (actually a friggin lot) that don't need nor want nor have the grunt to run d-bus |
| 17:13.26 | DocScrutinizer05 | and it's only a matter of time until systemd eats PA and makes that mandatory as well, as otherwise no "beep beep I'm up! Greetings, Poettering" audio on loading the kernel |
| 17:13.40 | nedko | DocScrutinizer05: what is more lightweight but has the same functionality than udev and d-bus? |
| 17:14.03 | DocScrutinizer05 | no d-bus |
| 17:14.07 | DocScrutinizer05 | no udev |
| 17:14.17 | nedko | no d-bus no udev -> no features they provide |
| 17:14.25 | DocScrutinizer05 | fsck the "functionality" |
| 17:14.33 | DocScrutinizer05 | so WHAT? |
| 17:14.39 | dos1 | but you don't always need features they provide |
| 17:14.45 | DocScrutinizer05 | exactly |
| 17:15.07 | dos1 | I know that SHR was using devtmpfs instead of udev for some time |
| 17:15.14 | DocScrutinizer05 | yep |
| 17:15.19 | DocScrutinizer05 | for example |
| 17:15.41 | DocScrutinizer05 | you can even run a system on statically configured devices |
| 17:16.06 | DocScrutinizer05 | and *d-bus*??? PFFF! |
| 17:16.39 | nedko | DocScrutinizer05: no IPC? or some other IPC mechanism? |
| 17:16.50 | DocScrutinizer05 | google IPC! |
| 17:17.01 | DocScrutinizer05 | it's not like d-bus invented that |
| 17:17.11 | dos1 | just checked, it's still using devtmpfs |
| 17:17.17 | DocScrutinizer05 | nor did Poettering |
| 17:17.22 | nedko | of course, dbus is just what is the best IPC we have on linux |
| 17:17.25 | dos1 | but well, together with systemd |
| 17:17.33 | nedko | maybe not for low resource systems though |
| 17:17.33 | DocScrutinizer05 | nedko: says WHO? |
| 17:17.46 | nedko | DocScrutinizer05: i say it |
| 17:17.50 | dos1 | but dunno if it would be still possible with upgraded systemd |
| 17:17.56 | DocScrutinizer05 | I'm proud to differ |
| 17:18.11 | nedko | DocScrutinizer05: this is why i asked you what you think is better |
| 17:18.41 | dos1 | dbus is the most popular IPC system |
| 17:18.48 | DocScrutinizer05 | I think I wouldn't be as silly as saying "XY is *best*" - since there never is ONE _best_ thing |
| 17:18.52 | dos1 | but that doesn't make it the best automatically |
| 17:18.59 | DocScrutinizer05 | exactly |
| 17:19.26 | kerio | dbus is a piece of crap, but it's the less shitty of the generic IPC systems |
| 17:19.30 | kerio | *least |
| 17:19.31 | nedko | of course, there are use cases when you don't event want linux |
| 17:20.01 | kerio | but, especially on an embedded system, why do you need a generic ipc system? |
| 17:20.01 | DocScrutinizer05 | and there are situations where I don't want to continue such discussions |
| 17:20.52 | nedko | i think the level of functionality/features maemo5 provides demands the features provided by dbus |
| 17:21.08 | DocScrutinizer05 | who said "maemo"? |
| 17:21.09 | nedko | maybe this is not embedded enough |
| 17:21.29 | DocScrutinizer05 | do we have systemd on maemo? NO WE DONT and I'm pretty happy about that |
| 17:21.31 | nedko | maemo is always implicit in this channel, no? :) |
| 17:21.33 | kerio | actually, even a lot less embedded |
| 17:21.37 | kerio | on a fucking server |
| 17:21.54 | kerio | why would i want dbus? |
| 17:21.59 | DocScrutinizer05 | indeed |
| 17:22.02 | kerio | or pulseaudio |
| 17:22.44 | DocScrutinizer05 | because damn Poettering thinks you mustn't have login without accessability and I18n support |
| 17:23.04 | DocScrutinizer05 | you MUST NOT |
| 17:23.21 | DocScrutinizer05 | or you're free to use... _not_ linux |
| 17:23.36 | dos1 | well, i'm using systemd on my pc; but each time when i remind myself that the same person who's responsible for it did pulseaudio, I think I might want to reconsider it ;] |
| 17:23.45 | nedko | i dont want to troll you but you sound like a datenwolf... :] |
| 17:24.28 | nedko | i dislike pulseaudio but i like systemd |
| 17:24.33 | DocScrutinizer05 | excuse me for not even googling the term, couldn't care less. please refrain from explaining it to me |
| 17:24.42 | nedko | it is a good thing for a dynamic system |
| 17:25.36 | DocScrutinizer05 | maybe the concept is a good one, the implementation is abysmal and unbearable |
| 17:26.12 | DocScrutinizer05 | so is the attitude driving it onto us |
| 17:26.39 | nedko | it is open source... |
| 17:26.54 | DocScrutinizer05 | go away with your "it's FOSS" |
| 17:26.57 | nedko | we are free to implement it better or improve it |
| 17:27.05 | dos1 | we are free to not use it |
| 17:27.16 | DocScrutinizer05 | which is the only alternative |
| 17:27.40 | nedko | dos1: this too :) |
| 17:28.12 | DocScrutinizer05 | you WLL NOTimprove the fucked up API |
| 17:28.24 | DocScrutinizer05 | you WILL NOT remove the d-bus dependencies |
| 17:29.15 | DocScrutinizer05 | it's like claiming "the plans for the hoover dam are public, you're free to improve them" |
| 17:29.39 | nedko | o.0 |
| 17:30.33 | DocScrutinizer05 | improving systemd means abolishing it and replacing it by something now (or old) |
| 17:30.33 | nedko | do you mean we don't have the resource to change the direction coprorate open source is pushing to? |
| 17:31.23 | DocScrutinizer05 | just like Poettering did with ALSA, though ALSA was easy to improve and add the allegedly missing capabilities PA was meant to deliver but failed *epically* |
| 17:31.56 | nedko | PA actually relies on ALSA |
| 17:31.59 | DocScrutinizer05 | s/sth now/sth new/ |
| 17:32.10 | nedko | in some aspect, PA extends ALSA |
| 17:32.20 | nedko | it doesnt abolish ALSA |
| 17:32.20 | DocScrutinizer05 | nedko: believe me *I* know that |
| 17:32.48 | DocScrutinizer05 | and no, it only depends on ALSA soundcard implementations |
| 17:33.10 | DocScrutinizer05 | since Poettering boggled from that part |
| 17:33.15 | nedko | not really but i'm not going to argue on this |
| 17:33.28 | nedko | at least not here |
| 17:33.53 | DocScrutinizer05 | anyway, I'm out. This discussion is futile |
| 17:50.53 | thedead1440 | wonders if poettering ever made it into any of the #maemo* chans; he would certainly be delighted :p |
| 17:54.27 | nedko | thedead1440: this [pa/systemd/udev thing] is hardly news |
| 17:54.44 | nedko | i was hit by it more than 5 years ago |
| 17:54.56 | nedko | lennart probably earlier |
| 17:56.31 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
| 17:57.37 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 18:03.18 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 19:10.08 | Pali | PA using kernel ALSA |
| 19:10.54 | Pali | because kernel ALSA is maybe only interface for kernel audio drivers (OSS in linux kernel is dead?) |
| 19:29.20 | nedko | app -> alsa (API) -> PA -> alsa (API) -> kernel |
| 19:29.45 | nedko | that said, alsa is overengeneered too :) |
| 19:32.46 | *** join/#maemo-ssu arcean_ (~arcean@aacr134.neoplus.adsl.tpnet.pl) |
| 19:38.30 | DocScrutinizer05 | "alsa (API)" is a pretty crappy compatibility layer |
| 19:38.43 | DocScrutinizer05 | the left one |
| 19:39.22 | DocScrutinizer05 | the right one is basically not existing, just "hw:0.0" soundcard ALSA kernel driver |
| 20:01.14 | kerio | kernel -> audio card is probably a lot more interesting |
| 20:01.35 | kerio | and we're lucky that it's too low level for lennart |
| 20:01.41 | kerio | or he would've fucked that up too |
| 20:27.22 | DocScrutinizer05 | ack |
| 20:55.26 | *** join/#maemo-ssu freemangordon_ (~freemango@213.137.35.49) |
| 21:01.02 | Pali | nedko: PA not using alsa userspace API |
| 21:01.10 | Pali | it using direct kernel API |
| 21:01.47 | Pali | (if lennart did not changed it) |
| 21:02.37 | Pali | ~poettering |
| 21:02.49 | Pali | ~lennart |
| 21:02.49 | infobot | Lennart is ~Poettering |
| 21:02.57 | Pali | ~Poettering |
| 21:03.16 | Pali | infobot dead? |
| 21:03.16 | infobot | yes :( |
| 21:04.11 | nedko | Pali: this is clarification not argument against my statement i guess? |
| 21:05.19 | Pali | just info which I known |
| 21:06.04 | Pali | I hate PA too |
| 21:06.41 | nedko | so you are telling me that PA talks to ALSA code in linux kernel not via libasound2? |
| 21:08.14 | Pali | last time (in past) when I looked into PA it does not used any alsa userspace dmix/filters |
| 21:08.40 | Pali | and grabbed kernel alsa card directly |
| 21:09.02 | Pali | exclusively |
| 21:09.33 | Pali | maybe it was changed... I do not want to look into PA sources |
| 21:10.02 | nedko | you can grab the card directly and exclusively via the normal user-space ALSA API |
| 21:10.06 | nedko | PA and JACK do this |
| 21:10.34 | Pali | I already read full lennart's ifplugd daemon and this was horrible... |
| 21:11.24 | Pali | I think that this guy does not know anything about networking and sockets |
| 21:11.44 | Pali | Using busy waiting... |
| 21:12.57 | nedko | i know for sure he knows this stuff very well, can you show an evidence to prove otherwise? |
| 21:14.10 | Pali | look into ifplugd source code |
| 21:14.26 | Pali | or if you are lazy run: $ strace ifplugd |
| 21:14.59 | Pali | with strace you will see at least busy waiting |
| 21:30.27 | nedko | Pali: are you talking about daemon_retval_wait() ? |
| 21:31.38 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 21:31.40 | Pali | nedko: I do not remember, but daemon did this: wait 1s, ask kernel for network adapter status, wait 1s, ask .... |
| 21:31.48 | *** join/#maemo-ssu wmarone (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 21:32.29 | Pali | I do not want to read that lennart's code again... |
| 21:47.43 | nedko | Pali: i read the code. and i think you are wrong. the code uses select() and there is indeed 1 second. it is used for things that you cannot do otherwise, no? |
| 21:48.14 | Pali | get network link status? |
| 21:48.21 | nedko | yup, seems like this |
| 21:48.25 | Pali | you can that |
| 21:48.51 | nedko | how you do it? |
| 21:48.55 | Pali | open netlink socket |
| 21:49.09 | Pali | send some data |
| 21:49.37 | Pali | and kernel will send you info when link change |
| 21:49.53 | Pali | do not know all needed flags for netlink |
| 21:49.58 | Pali | but it is possible |
| 21:50.18 | nedko | http://git.0pointer.de/?p=ifplugd.git;a=blob;f=src/interface.c;h=c7747889639e55e5de71f20811d00b4315d4855c;hb=HEAD#l46 |
| 21:50.28 | nedko | IIRC you cannot detect the carrier this way |
| 21:51.03 | nedko | i.e. UP != LOWER_UP |
| 21:51.09 | nedko | but i may be wrong |
| 21:51.27 | Pali | for sure you can |
| 21:51.29 | Pali | but via netlink socket |
| 21:51.52 | nedko | hmm, maybe i gave wrong link... |
| 21:51.52 | Pali | and not using SIOCGIFFLAGS |
| 21:52.09 | Pali | ifplugd is badly written |
| 21:52.20 | Pali | and using that SIOCGIFFLAGS with busy waiting |
| 21:52.33 | *** join/#maemo-ssu sailus (~sailus@valkosipuli.retiisi.org.uk) |
| 21:52.50 | nedko | Pali: was it possible when lennart wrote that code? |
| 21:53.13 | Pali | I do not know |
| 21:53.30 | Pali | but this is still present in last version |
| 21:53.39 | nedko | the last version is quite old |
| 21:53.40 | Pali | which is widely used |
| 22:02.58 | Pali | nedko: RTM_GETLINK should be that netlink packet type |
| 22:04.02 | Pali | and RTMGRP_LINK group |
| 22:06.01 | nedko | the code already uses RTMGRP_LINK |
| 22:07.05 | nedko | so i wonder why he still polls |
| 22:08.03 | Pali | because he is lennart? |
| 22:08.47 | nedko | yeah, ad hominem works :-/ |
| 22:11.34 | nedko | latest ifplugd release is from 2005, the kernel documentation networking/operstates.txt was added in 2006 |
| 22:13.06 | Pali | and why he using RTMGRP_LINK before? |
| 22:17.42 | nedko | Pali: IFF_LOWER_UP was introduced in 2006 as well, after the latest ifplugd release |
| 22:20.23 | nedko | Pali: 2006 as well: http://lkml.indiana.edu/hypermail/linux/kernel/0602.2/1883.html |
| 22:22.28 | nedko | and he wrote that code in 2003 |
| 22:22.35 | Pali | hm, ok |
| 22:25.42 | Pali | nedko: read that thread |
| 22:25.45 | Pali | and last email: http://lkml.indiana.edu/hypermail/linux/kernel/0602.2/2287.html |
| 22:26.30 | nedko | Pali: still 2006, three years after lennart wrote the ifplugd code for NETLINK stuff |
| 22:27.38 | Pali | in above email is written that it was possible before above patch... but I do not want to look into history... maybe really there was no API |
| 22:28.08 | Pali | what is bad is that last version of ifplugd does not support it and it is used in 2013 |
| 22:28.23 | nedko | i agree |
| 22:41.58 | *** join/#maemo-ssu oooaaaooo1 (~rootzilla@d122-109-46-88.per802.wa.optusnet.com.au) |
| 23:58.18 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |