**** BEGIN LOGGING AT Wed Jan 27 02:59:57 2010 Jan 27 03:01:45 cshore: pong Jan 27 03:02:59 nbd: You know how the hostapd (package Makefile; for all it's 'friends') works? Jan 27 03:03:34 nbd: it seems that when using OpenSSL as the TLS provider the compilation fails for wpa_supplicant and wpad-mini Jan 27 03:04:06 nbd: by the way it sounds like the latest patch fixes the brcm-2.4 Jan 27 03:04:11 and 47xx Jan 27 03:10:55 cshore: oh, seems i forgot to test the openssl tls provider. will look into that tomorrow Jan 27 03:13:24 what do you need openssl for? Jan 27 03:13:24 nbd: thnx Jan 27 03:14:24 nbd: well we use packages that require openssl (I forget which ones), so we set all the ssl providers to openssl to save space, rather than have multiple ssl builds Jan 27 03:14:54 i don't think it'll save much space Jan 27 03:14:59 the internal stuff is very small Jan 27 03:15:20 especially for the -mini version Jan 27 03:16:21 nbd: how many k? Jan 27 03:17:04 not sure Jan 27 03:18:23 nbd: we're using the internal for now because of the openssl problems Jan 27 03:18:55 nbd: I'll check the build size and see if it's noticeable Jan 27 03:25:14 i just took a look at the src/crypto/ object files Jan 27 03:25:18 added together they're 77k Jan 27 03:25:40 but that's probably including a lot of overhead that you get from the elf headers and stuff Jan 27 03:25:57 so the space wasted is much less than the space gained by using wpad instead of hostapd+wpa_supplicant ;) Jan 27 03:26:08 nbd: heh Jan 27 03:26:26 So if you compile wpad do you not need wpa_supplicant? Jan 27 03:26:38 it's a multicall binary of hostapd and wpa_supplicant Jan 27 03:26:52 contains full functionality of both Jan 27 03:26:59 and the command line is compatible Jan 27 03:27:10 ok, so one now *only* selects wpad (or wpad-mini)? Jan 27 03:27:21 yes Jan 27 03:27:26 nbd: cool Jan 27 03:33:17 will insmod usb-storage automatically load usbcore? Jan 27 03:33:35 no Jan 27 03:33:38 or usb-ohci ? Jan 27 03:33:45 no dependency tracking in modules Jan 27 03:33:47 that is usb-ohci load usbcore Jan 27 03:33:51 nbd: ah, ok Jan 27 03:34:02 nbd: that's what I needed to know Jan 27 03:34:26 nbd: I'm working on a package for root on usb, now Jan 27 03:35:04 great Jan 27 03:35:15 many people have been waiting for that to be properly supported Jan 27 03:35:44 there were some hacks in the forum/wiki, but iirc none of those were particularly good Jan 27 03:36:36 btw. it would be really useful to have the rootfs configuration configurable in the flash rootfs Jan 27 03:36:52 i.e. have the script mount the jffs2 part once without mini_fo, look for the next filesystem on there Jan 27 03:36:59 and then umount it and proceed Jan 27 03:37:27 nbd: yes, I'm planning on using the jffs2 to store the UUID Jan 27 03:37:33 nbd: as well as for fallback Jan 27 03:37:38 great Jan 27 03:38:04 nbd: there's a lot of pieces to get it right Jan 27 03:39:01 nbd: especially now with hotplug...but I wanted to change 10-mount anyway, so this is as good a reason as any Jan 27 03:40:06 nbd: because for one thing we don't want it to mount on firstboot until we've formatted and copied the squashfs (or /dev/root for ext2 or all_jffs2) Jan 27 03:41:32 yeah, imho the user should run the formatting and partitioning himself Jan 27 03:41:46 with some scripts that make thins process simple without risk of overwriting existing data Jan 27 03:41:49 nbd: I think the system should reboot after firstboot though...I'm not sure we can have it in a suitably consistent state without doing so, unless we forgo the jffs being formatted in firstboot Jan 27 03:42:39 the script that enables the use of external rootfs can check whether the jffs2 initialization has finished Jan 27 03:42:44 after the configuration Jan 27 03:42:56 and when the setup is done, it tells the user to reboot the system Jan 27 03:43:07 because mini_fo unmounting does not work cleanly iirc Jan 27 03:43:12 nbd: hmmm Jan 27 03:43:16 nbd: ah, right Jan 27 03:43:49 nbd: I'm trying to figure out also an automated system for our service provider deployments Jan 27 03:43:57 nbd: but that's a special case Jan 27 03:44:14 nbd: I might make it part of the failsafe/provisioning Jan 27 03:44:14 yeah, the user interaction could be circumvented by setting defaults in openwrt menuconfig Jan 27 03:44:21 nbd: yes Jan 27 03:44:54 nbd: but not enabled by default Jan 27 03:45:05 nbd: so that the user only gets it if they know what they're doing Jan 27 03:45:15 right Jan 27 03:46:33 nbd: okay, time to rewrite my pseudocode a bit then Jan 27 03:58:25 build #19 of ar7-trunk is complete: Failure [failed compile_6 compile_15] Build details are at http://tksite.gotdns.org:8010/builders/ar7-trunk/builds/19 Jan 27 03:59:09 build #31 of brcm63xx-trunk is complete: Failure [failed svn] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx-trunk/builds/31 Jan 27 03:59:38 nbd: this actually makes my life easier Jan 27 04:00:48 nevermind the builder I am reconfiguring the buildbotr Jan 27 04:06:47 nbd: I suppose for the config file I should actually parse it rather than just eval'ing each line Jan 27 04:06:56 nbd: since it's user writable Jan 27 04:07:56 nbd: guess I need uci...but I have to use the alternate directory thingy Jan 27 04:08:12 nbd: since jffs will still be on /jffs Jan 27 04:08:41 nbd: shouldn't distclean have output with V=99? Jan 27 04:09:00 cshore: uci supports using an alternate config directory Jan 27 04:09:19 thepeople: i don't think it produces much output Jan 27 04:09:33 nbd: yes, but I have to modify the /lib/whatever uci.sh to use it Jan 27 04:09:45 nbd: it doesn't produce any output Jan 27 04:10:27 nbd: causes issues with the buildbot as it will timeout the command if it lasts more than 1200 seconds without output Jan 27 04:10:46 cshore: you could add an optional variable for specifying the config directory Jan 27 04:10:52 cshore: which gets used in config_load() Jan 27 04:11:05 nbd: that's my plan Jan 27 04:11:08 nbd: which is good to have incase something gets stuck (happens to the perl compile from time to time) Jan 27 04:11:34 thepeople: i'll try to find the time to look into it tomorrow Jan 27 04:12:20 nbd: thanks Jan 27 04:21:36 i've tried building the b43 driver in trunk (revision 19331) and i'm getting a whole bunch of unresolved symbols when i try to load the driver on the device (routerstation pro) am I doing something simple wrong here or is the B43 driver not working (i get the same problem with b43legacy) Jan 27 04:21:59 (ath9k is working) Jan 27 04:27:08 nbd how does http://openwrt.pastebin.com/d60ccbc4f look to you? Jan 27 04:29:53 cshore: looks wrong Jan 27 04:30:02 nbd: doh Jan 27 04:30:36 replace /etc/config with $UCI_CONFIG_DIR ;) Jan 27 04:31:11 right...I hate :+ I always get confused Jan 27 04:34:19 http://openwrt.pastebin.com/d214e7cc1 better? Jan 27 04:34:57 yup Jan 27 04:34:59 did you test it? Jan 27 04:35:19 not yet...getting a first blush look at it first... Jan 27 04:42:49 I tested both with and without a config dir using: Jan 27 04:42:52 http://openwrt.pastebin.com/d7f73590b Jan 27 04:43:27 I just edit the file for the non config dir test) Jan 27 04:44:01 do you want me to test all functions? Jan 27 04:49:56 i think the patch is fine Jan 27 04:50:45 nbd: will you commit it, or should I post it to -devel? Jan 27 04:50:56 i'll commit it Jan 27 04:51:03 :-D Jan 27 04:51:39 now I don't have to invent a parser Jan 27 04:51:44 can you try openwrt.pastebin.ca instead of openwrt.pastebin.com? Jan 27 04:51:58 sure: is there a reason? Jan 27 04:51:58 it seems like pastebin corrupted the patch Jan 27 04:52:00 ;) Jan 27 04:54:06 http://openwrt.pastebin.ca/1767620 Jan 27 04:57:17 my poor innocent patch...corrupted by the evil bin of paste Jan 27 04:57:57 I always new Canadians did it better :-P Jan 27 04:58:11 but can't spell, eh? Jan 27 04:59:17 nbd * r19351 /trunk/package/uci/files/lib/config/uci.sh: uci: allow shell scripts to override the config dir (patch by cshore) Jan 27 05:19:43 thnx nbd Jan 27 05:28:53 ping rtz Jan 27 06:24:51 anyone around to close some tickets? Jan 27 06:31:34 swalker: well if you have any to ask me about I can tell you, but I don't have Trac access to actually close any Jan 27 06:33:52 looks like https://dev.openwrt.org/ticket/3775 is the ticket puchu was wanting Jan 27 06:34:26 probably won't be any to ask about unless they patches Jan 27 06:35:06 swalker: I think most of mine have actually been fixed Jan 27 06:35:16 I'd really like a bugzilla system for that type of searching Jan 27 06:35:50 swalker: yeah....I guess the advantage of Trac is that it's lightweight and integrated with source browsing Jan 27 06:36:43 swalker: and I have to admit trac is easier to submit bugs with Jan 27 06:56:06 is wrt600n support still a wip? looks like some netconfig vlan changes are still needed, see https://dev.openwrt.org/ticket/4168 Jan 27 07:20:15 cshore: you still have a few mount tickets around, #5057 being a dupe of #5478 Jan 27 07:20:35 swalker: yes, I'm working on those Jan 27 07:21:53 yeah, I'd like to see the seemingly boatload of tickets closed when that gets fixed Jan 27 07:22:29 swalker: have others been posting tickets? Jan 27 07:23:59 #6540 is fixed btw Jan 27 07:25:44 at least #2752 Jan 27 07:29:44 hmm....well I'm working on root on usb right now Jan 27 07:29:55 which will involve changes to 10-mount as well Jan 27 07:29:58 (hotplug) Jan 27 07:30:48 #5719 is fixed, #5350 needs to be duped to #5779, #6436 was fixed with r19302, #5697 is a dupe of #3531 which was fixed in r17478, #3432 & #3702 should be invalid after r14289 Jan 27 07:32:37 #3554 is another external root ticket Jan 27 07:33:04 swalker: hmmm....one thing that's a problem is if the device gets pulled while it's root...that's bad Jan 27 07:34:59 swalker: but AFAIK not one that I'll worry about because it's pretty much insoluble Jan 27 07:36:22 I mean intractable Jan 27 07:42:04 swalker: you're right there are a boatload Jan 27 07:43:41 what types of USB host controller are there (and what modules do they use?) I know ohci and uhci Jan 27 07:44:30 also, what external fs's are supported that are suitable for root (e.g. not vfat) Jan 27 07:44:54 ext2/3/4, reiserfs? Jan 27 07:47:57 xfs, btrfs? Jan 27 07:48:18 hmmm...ok Jan 27 07:49:46 possibly needing the patch in #6215 for ext4 Jan 27 07:56:54 what are some non-usb sorage controllers (e.g. the IDE ones)? Jan 27 08:21:59 for config (menuconfig) files is there a way to specify optional additional config options? Jan 27 08:22:08 e.g. to load additional modules Jan 27 08:22:21 or do I have to have a slot for it, always Jan 27 08:22:44 (well if a [*] Additional modules is selected) Jan 27 10:46:37 http://www.compex.com.sg/fullDescription.aspx?pID=1 Jan 27 11:19:04 where is the right place to do a brctl? Jan 27 11:22:27 can someone please explain to me how the configuration of network interfaces is supposed to work in openwrt? Jan 27 11:22:39 i find examples with brctl and ifconfig directly in preinit! Jan 27 11:24:15 than i don't understand what is the purpose of etc config network Jan 27 11:32:27 <[Fate]> /etc/config/network is where you should do the configuration Jan 27 11:32:39 <[Fate]> it's largely hardware-independent Jan 27 11:39:07 so no parameters in the kernel? Jan 27 11:40:01 <[Fate]> does configuring as described in http://kamikaze.openwrt.org/docs/openwrt.html not work for you? Jan 27 11:40:50 i have to recheck Jan 27 11:40:57 thx for the link anyway Jan 27 11:41:32 i have an evaluation board with some things in preinit and some others in other etc network Jan 27 11:44:46 Lllaso: preinit's just changed, so whatever was in preinit would have to be updated for it anyway, so now is a good time to switch to a proper /etc/config/network setup Jan 27 11:45:11 Lllaso=Lalloso Jan 27 12:02:26 mmm okay Jan 27 12:02:32 but even before mounting root fs Jan 27 12:02:36 i get a kernel message Jan 27 12:02:51 IP-Config: device 'eth0' not found Jan 27 12:02:59 could this be due to kernel command line? Jan 27 12:04:18 <[Fate]> first thing I'd think would be: missing driver Jan 27 12:04:38 Lalloso: what platform? Jan 27 12:04:47 Lalloso: fresh build? Jan 27 13:12:46 it's my evaluation board cshore Jan 27 13:12:55 and it's unfortunately not a fresh build Jan 27 13:13:11 is it probably something wrong in the kernel command line passed by uboot Jan 27 13:14:09 Lalloso: I would do a fresh build for starters Jan 27 13:14:42 I would like to Jan 27 13:14:52 but I think I have some custom things here and there Jan 27 13:15:05 I should do a check out of openwrt svn Jan 27 13:15:13 and svn diff it against my current tree Jan 27 13:15:35 I've heard you have been very busy these days adjusting the openwrt boot sequence Jan 27 13:15:54 did it have something wrong? Jan 27 13:25:33 swalker * r19352 /packages/net/transmission/Makefile: [packages] transmission: update to 1.82 (#6555) Jan 27 13:28:56 swalker * r19353 /packages/utils/pciutils/Makefile: [packages] pciutils: update to 3.1.6 Jan 27 13:30:41 Lalloso: it was to add the ability to do drop in packages that alter the behaviour of the boot sequence, without the need for always rewriting the preinit and the problems that creates in terms of having to maintain a separate tree, and the difficulty in getting changes merged Jan 27 13:31:32 i see Jan 27 13:32:06 but which is the software entity that should bring up the network interfaces? Jan 27 13:32:25 and which is the software entity that should read /etc/config/network ? Jan 27 13:32:40 Lalloso: actually that normally happens in /etc/init.d/network Jan 27 13:32:51 Lalloso: nothing to do with preinit Jan 27 13:33:11 Lalloso: but your custom stuff may be different, so I can't help you much Jan 27 13:33:19 but that /etc/init.d/network is also involved with br0 or just with eth0 ? Jan 27 13:33:28 Lalloso: all Jan 27 13:33:48 Lalloso: also /lib/network/* Jan 27 13:34:03 well theres one point in the init where the network is touched, to setup the network failsafe ip Jan 27 13:34:13 right Jan 27 13:34:35 it's strange Jan 27 13:34:48 because if i issue /etc/init.d/network start Jan 27 13:34:50 it seems to work Jan 27 13:34:57 but it does not start automatically at boot Jan 27 13:35:05 even if I have /etc/init.d/network enabled Jan 27 13:35:16 jow_laptop: but on brcm63xx there is no iface defined for preinit Jan 27 13:35:24 jow_laptop: that setup has nothing to do with what will happen thereafter Jan 27 13:35:37 Lalloso: does hotplug see your interface Jan 27 13:35:43 Lallso: I forgot about hat Jan 27 13:35:48 ping nbd Jan 27 13:36:09 Lalloso: interfaces are now hotplugged rather than brought up by /etc/init.d/network Jan 27 13:36:20 Lalloso: I keep forgetting that Jan 27 13:36:27 nbd your idea with the openssl dynamic flag is ready ... but u forgot the mention that a Config.in is needed for this .... Jan 27 13:36:28 mmm this add complexity Jan 27 13:37:04 Lallso: when are the iface modules insmod'ed? Jan 27 13:37:24 I think they are not modules but they are in the kernel Jan 27 13:37:27 is that possible? Jan 27 13:38:13 Lalloso: yes...actually, I lied they're generally not modules Jan 27 13:39:02 Lallso: but they should be coldplugged when hotplug is started up Jan 27 13:39:39 how this hotplugging system is supposed to work? Jan 27 13:40:05 Lalloso: when first started events are created for devices already known to the kernel Jan 27 13:40:14 I guess I could remove any brctl command and ifconfig command from preinit Jan 27 13:40:23 Lalloso: then as devices are added addtional events are added Jan 27 13:40:36 put everything in /etc/config/network and keep init.d/network enabled Jan 27 13:40:55 so hotplug is a service in /etc/init.d ? Jan 27 13:41:09 Lalloso: no, it's started in preinit Jan 27 13:41:54 and it has some configuration or? Jan 27 13:42:23 Lalloso: so come to think of it, it could be executing during preinit Jan 27 13:42:52 Lalloso: I'm not sure how it works for dealing with the devices added before jffs is mounted Jan 27 13:43:06 eh this is very interesting indeed Jan 27 13:43:09 without jffs Jan 27 13:43:18 there is no /etc/config/network to read :-) Jan 27 13:43:34 Lalloso: well really the default one in squashfs Jan 27 13:44:10 Lalloso: so in short: jow_laptop, do you know? Jan 27 13:44:41 I have no squashfs on my board it's just jffs2 but i understand your point Jan 27 13:44:46 you are talking about the mini_fo Jan 27 13:44:57 Lalloso: yes Jan 27 13:45:10 preinit could read the squashfs version of /etc/config/network waiting for the modified version in jffs2 to become available Jan 27 13:45:32 Lallso: I don't think that's how it works...I'm a little confused now, myself Jan 27 13:46:01 Check /etc/init.d/boot Jan 27 13:46:12 maybe it does some initialization there Jan 27 13:47:42 Lalloso: because it works correctly here, so I assume I'm missing something Jan 27 13:50:11 but how the coupling of physical ports with labels as eth0 is achieved? Jan 27 13:59:19 Lalloso: I believe the kernel does that Jan 27 14:00:25 preinit_ip Initialize network interface (if one has been defined for as available for preinit) Jan 27 14:00:38 from http://cshore.is-a-geek.com/openwrt/preinit_mount.html#preinitoverview Jan 27 14:00:57 Lalloso: doesn't apply to your build Jan 27 14:01:44 http://cshore.is-a-geek.com/openwrt/preinit_mount.html#customizing Jan 27 14:02:00 because this is the new way while I have the old way? Jan 27 14:02:10 Lalloso: right Jan 27 14:02:15 isn't this site i'm linking your site actually? :) Jan 27 14:02:24 Lalloso: yep Jan 27 14:02:46 Lalloso: it's the wiki now actually: http://wiki.openwrt.org/doc/techref/preinit_mount Jan 27 14:53:12 but /etc/init.d/network at times complain about something regarding iptables Jan 27 14:53:27 but i don't have any iptables stuff in /etc/config/network Jan 27 14:54:13 Lalloso, when the interfaces are brought up it causes firewall events to occur Jan 27 14:54:37 this things is not linear Jan 27 14:54:52 how can I debug if random things happen at random times? Jan 27 14:55:07 I have eth0 which is phisycally bridged within a switch Jan 27 14:55:36 and eth1 which is standalone Jan 27 15:33:43 swalker * r19354 /packages/utils/usb-modeswitch/Makefile: [packages] usb-modeswitch: update to 1.1.0 (#6576) Jan 27 16:01:09 ping xMff Jan 27 16:01:57 . Jan 27 16:04:02 xMff: if one does has an uci section config 'main' Jan 27 16:04:02 will config_get var main option Jan 27 16:04:02 retrieve the option from config section main, or does the section need a name? Jan 27 16:04:45 it needs a name, else you have to resort to config_foreach Jan 27 16:04:59 ok, thanks Jan 27 16:23:38 is there a reason hotplug is enable before root is mounted and init begins? Jan 27 16:24:01 cshore: yes Jan 27 16:24:12 cshore: mainly for coldplugging Jan 27 16:24:41 rtz: what devices need to be coldplugged for preinit? Jan 27 16:25:02 rtz: that is, why can it be delay until either just before init or after init? Jan 27 16:25:16 can't be delayed Jan 27 16:26:42 cshore: sorry, lost connection Jan 27 16:26:44 cshore: network, reset button (that's actually a hotplug event), console, block devices for the filesystem ... Jan 27 16:26:53 I'm sure I forgot some Jan 27 16:27:29 rtz: basically anything that's in the kernel Jan 27 16:27:34 yes Jan 27 16:27:52 well, maybe not Jan 27 16:28:02 there are some things, that could wait a bit Jan 27 16:28:04 rtz: hmmm....this makes life difficult Jan 27 16:28:16 but everything you need, to mount the root fs and enter failsafe Jan 27 16:28:37 rtz: it means some filesystem my be trying to mount before the rootfs Jan 27 16:28:57 rtz: e.g. on x86 if usb is in the kernel but you want root on external usb Jan 27 16:30:43 rtz: does jffs generate a coldplug event? Jan 27 16:31:14 cshore: nothing you need afaik Jan 27 16:31:25 cshore: but you do need the device node for it Jan 27 16:31:48 cshore: i mean, it doesn't create anything useful, when it's mounted Jan 27 16:32:25 rtz: I just mean, before it's mounted, when hotplug is started, does it generate a block device add event Jan 27 16:33:02 rtz: because if it does mounting could be made an entirely hotplug thing Jan 27 16:33:19 rtz: forget about trying to do it partially in preinit Jan 27 16:33:36 cshore: yes Jan 27 16:34:56 rtz: I think IPC is needed...we need to mount certain fs before others Jan 27 16:34:59 cshore: but it creates only a event for a mtd* device, so you would have to check, if it's the rootfs_data partition Jan 27 16:35:04 but that's not that hard Jan 27 16:35:56 rtz: but if you've got both mtd and usb, order is not guaranteed, right? Jan 27 16:38:40 cshore: i'm not exactly sure, what you meen by order, but the answere is most likely no Jan 27 16:39:00 cshore: 1. there is no ordering between the coldplug events afaik Jan 27 16:39:09 I mean usb could come before mtd or vice versa Jan 27 16:39:25 2. usb doesn't create a mtd node, it creates /dev/sda* Jan 27 16:39:26 yes Jan 27 16:41:11 ok....but I know we have tmpfs before hotplug started, so we can use that for IPC Jan 27 16:44:43 current preinit isn't quite right, especially as is, for the fact we now have hotplug Jan 27 16:48:52 rtz: we need dependencies for dealing with hotplug events, and a way to defer decisions on what to do until preconditions are met Jan 27 16:49:44 cshore: I toyed with the idea to stuff hotplug into my init daemon, but not sure if that's a good idea Jan 27 16:50:35 rtz: I thought that was the point Jan 27 16:51:23 well, it was planned as a service startup daemon Jan 27 16:52:44 rtz: I don't see event-based service start as necessary unless it is so that services start in response to events like device adds, and/or for dealing with the dependencies of the events and services Jan 27 16:55:14 dependencies was planned, device add/remove only as an idea, but I can add it Jan 27 16:56:11 rtz: I think I might work on modifying hotplug.rules Jan 27 17:02:59 rtz: is /dev/shm supposed to be a place for things like IPC sockets? Jan 27 17:04:27 <[Fate]> /dev/shm is for shared memory Jan 27 17:17:36 <[Fate]> mhm i2c-gpio does not depend on i2c-core? Jan 27 17:20:20 if you create /dev/console (mknod) can you access the serial console without hotplug doing coldplug? Jan 27 17:20:59 cshore: yes and no Jan 27 17:21:10 cshore: 1. /dev/console is not what you want Jan 27 17:21:34 cshore: it's something like /dev/ptmx (depending on the hotplug daemon) Jan 27 17:21:45 cshore: 2. creating those should be enough Jan 27 17:23:10 I thought ptmx was the pseudo-terminal, which is used if there is no real terminal available Jan 27 17:24:29 rtz: also, can reset button events be detected without hotplug? Jan 27 17:24:36 cshore: something like this Jan 27 17:25:07 cshore: /dev/console is the currently used console, I think Jan 27 17:25:41 cshore: I'm not completly sure about this, I only guess this from the lines with M0 and M1 in the original preinit Jan 27 17:26:12 cshore: as to button events, not easiely Jan 27 17:26:59 cshore: buttons are basically handled as a standard input device like mice or the keyboard Jan 27 17:27:02 cshore: okay, then I know...those are pseudo-terminal and are used for stdin/stdout if there is no serial terminal, because ash doesn't like not having stdio Jan 27 17:27:23 cshore: a button creates a specially keypress event Jan 27 17:27:47 cshore: and you can't access the input devices from the shell afaik Jan 27 17:28:10 cshore: nope Jan 27 17:28:22 cshore: they are used, if the IS a serial terminal Jan 27 17:28:49 cshore: otherwise, /dev/console is used for stdio (not sure what effect this has) Jan 27 17:29:37 or waint Jan 27 17:29:37 rtz2: I'm trying figure the minimal environment that would allow failsafe (including entry via reset button), preferably without hotplug Jan 27 17:29:40 wait Jan 27 17:29:46 maybe I'm wrong Jan 27 17:30:58 cshore: sorry, you were right, I messed it up Jan 27 17:31:17 cshore: /dev/ptmx is only used, if there is no console available Jan 27 17:31:26 rtz2: it's okay...we all have those times Jan 27 17:32:39 rtz2: the reset button is a module, right? Jan 27 17:33:41 cshore: usually Jan 27 17:34:24 cshore: by default you need, input-core, input-polldev, gpio_buttons and button-hotplug Jan 27 17:34:50 cshore: maybe with some other - and _ Jan 27 17:35:03 and it's button-hotplug that generates SIGUSR1? Jan 27 17:35:11 cshore: nope Jan 27 17:35:18 it creates a hotplug event Jan 27 17:35:38 cshore: take a look at /etc/hotplug2-init.rules Jan 27 17:35:58 why does preint trap SIGUSR1 for reset button events? Jan 27 17:36:31 cshore: there is a rule hotplug2-init.rules for buttons: exec kill -USR1 1 Jan 27 17:36:42 rtz2: ah, ok Jan 27 17:36:50 cshore: 2 other things Jan 27 17:37:30 cshore: 1. I don't see a very good reason, why it shouldn't be possible to link the button stuff directly into the kernel, if this helps you Jan 27 17:37:49 cshore: 2. some platfroms my be able to generate irqs for gpio lines Jan 27 17:38:01 those may need a different set of modules Jan 27 17:38:17 rtz2: I actually don't care about irqs, only about being able to access button state Jan 27 17:39:11 cshore: I tried to do the same thing, but I didn't find an easy solution, so i shelfed it Jan 27 17:39:28 rtz2: being able to access a gpio and check if it's pressed or not would be enough Jan 27 17:41:34 cshore: that's easy Jan 27 17:41:50 echo 1 > /sys/class/gpio/export Jan 27 17:42:05 wait Jan 27 17:42:12 echo > /sys/class/gpio/export Jan 27 17:42:40 echo in > /sys/class/gpio/gpio/direction Jan 27 17:42:52 cat /sys/class/gpio/gpio/value Jan 27 17:43:07 cshore: maybe some lightly different paths Jan 27 17:43:12 s Jan 27 17:43:38 cshore: but you have to be careful Jan 27 17:44:14 cshore: if the gpio is already used somewhere in the kernel (say, the gpio_buttons driver), you won't be able to export it Jan 27 17:44:45 what does the gpio_buttons driver do? Jan 27 17:45:34 cshore: provide an input device mapping to gpio lines Jan 27 17:46:07 cshore: you tell him gpio #3 is connected to a button and it does the rest Jan 27 17:46:23 rtz2: the rest as in? Jan 27 17:48:10 cshore: create a polling input device and set it up to poll the requested gpio lines Jan 27 17:48:30 and create the keypress events, in case the button is pressed Jan 27 17:48:58 rtz2: which you can't access without hotplug? Jan 27 17:49:27 rtz2: could you write C program to catch the events? Jan 27 17:49:41 cshore: actually, you normally can't access them with hotplug Jan 27 17:49:56 cshore: that's what the buttons_hotplug driver is for Jan 27 17:50:15 cshore: maybe Jan 27 17:50:37 cshore: I will take a look at it and come back to you later this evening Jan 27 17:50:46 rtz2: thanks! Jan 27 17:50:52 one more question Jan 27 17:51:14 cshore: by the way, you remember your idea with different press patterns leading to different failsafe behavior? Jan 27 17:51:17 can you access ethernet devices without hotplug/coldplug? Jan 27 17:51:21 rtz2: yes? Jan 27 17:51:34 cshore: you are in for a world of hurt Jan 27 17:51:46 rtz2: debounce problems? Jan 27 17:52:20 cshore: actually, no, you shouldn't have those with polled devices Jan 27 17:53:04 cshore: but matching a given pattern to a list of expected patterns won't be easy Jan 27 17:53:28 cshore: not unsolveable, but it will require some toughts and research Jan 27 17:53:43 rtz2: okay Jan 27 17:54:03 cshore: as to ethernet devices, try to delete the dev node and check if ifconfig still works Jan 27 17:54:44 cshore: if not, you manually creating /dev/eth0 will probably be enough Jan 27 17:54:45 rtz2: what device node?....I didn't think ethers had a /dev Jan 27 17:54:56 they aren't? Jan 27 17:54:59 hmm Jan 27 17:55:20 they were some time ago, but not sure how it is now Jan 27 17:55:35 I just checked...no /dev Jan 27 17:55:44 well, it should work then Jan 27 17:56:05 ok, I think I'm going to modify preinit (again) Jan 27 17:56:17 cshore: by the way, did you take a look at devfs 2.0 (I think it's in 2.6.32) Jan 27 17:56:26 rtz2: not yet Jan 27 17:56:45 it should work fine without any hotplug daemon at all Jan 27 17:56:58 rtz2: what happens to hotplug? Jan 27 17:57:11 rtz2: and events? Jan 27 17:58:10 rtz: or does one use hotplug if one wants events, and otherwise it just creates the device nodes? Jan 27 17:58:11 <[Fate]> could someone pls review the patch in https://dev.openwrt.org/ticket/6589 if he/she has the time? Jan 27 17:59:04