=== sethmahoney [n=seth@67-42-7-62.ptld.qwest.net] has joined #ubuntu-boot === sethmahoney [n=seth@67-42-7-62.ptld.qwest.net] has left #ubuntu-boot [] === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-boot === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-boot === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-boot [08:33] Keybuk: you got your ubuntulog [08:33] thanks [08:34] Keybuk: anyway the best is to just send me a mail [08:35] becuase the bot is like -20 in my priority list :) [08:35] is that nice -20, or ... ? :p [08:36] ehhe [09:12] infinity: random question; are we leading the initramfs-tools versions or are Debian? ... I'm making quite major changes, so it would feel more natural to release it was 0.40ubuntu1 or something [09:22] ubuntu is behind atm. [09:23] fsvo "behind" [09:23] all the changes in your 039 are irrelevant for ubuntu [09:23] we have changes jbailey ok'ed but didn't want to push yet for breezy [09:24] and replaced by those in our 040, which won't work for Debian [09:24] (or whatever version we use for it) [09:24] We haven't merged with Debian yet, nor have I had time to tell makx what Debian changes I think are utter crack so we can merge the other direction. [09:24] So, pick a version number at random, and make sure it has "ubuntu" in the name, and we'll sort it later. :/ [09:24] infinity: ok === infinity has been too busy to do much of anything with it and, frankly, has been ignoring initramfs while you've had your hardware activation lock on it. [09:25] So, hurry the heck up. :) [09:25] am doing my changes right now :) so the lock will be released once these are done and uploaded [09:26] you still don't have a manpage for update-initramfs [09:26] infinity: one thing I'm considering ... would it make more sense to provide initramfs-tools hooks and scripts in udev, which will just get copied in, rather than hardcoding use of udev into initramfs-tools ? [09:27] Keybuk: yes [09:27] we already have an hooks/udev [09:28] inifinity: please tell what is utter crack? [09:28] Keybuk : That would be beyond fine. [09:28] Keybuk : In fact, that's what we SHOULD be doing. [09:28] Keybuk : The less package-specific cruft we have in initramfs, the better. [09:29] Keybuk : If that approach can be done in both Debian and Ubuntu, our diffs may get very small again. [09:29] ok, because scripts/init-top/udev makes a lot of sense to me [09:29] along with hooks/udev to copy over things [09:29] (Which is one motivation for making it work that way) [09:29] and ship those in udev itself, rather than in initramfs-tools [09:30] makx : Nothing is "utter crack" so much as stuff that should be discussed. I was being overly dramatic for effect. :) [09:30] Keybuk : Yes please. [09:31] infinity: evms will move to it's package what else is bad? [09:31] evms was one, yes. [09:31] Realistically, anything that can be factored back out (and our own implementation was guilty of this before you started hacking on it) should be removed. [09:32] The more initramfs is kept as a flexible framework with very little actual "content", the better. [09:32] actually, now I think about it, it should be init-premount as otherwise it'll happen before module loading -- and conf/modules should happen first [09:33] I'm also wondering at what stage we should declare klibc a failed experiment, and just use glibc everywhere. [09:33] do we have everything in busybox? [09:33] infinity: the klibc utilities are useful, but that's it [09:33] Keybuk : What does klibc ship that we couldn't get from turning on some busybox options? [09:34] (or building a few tiny binaries of our own, linked against glibc) [09:34] would help a lot on Debian, klibc isn't ready for quite some archs [09:35] infinity: no idea, the binaries that come with klibc are tiny [09:35] we could just copy anything there we didn't have in busybox [09:35] run-init is probably the main one ;) [09:38] Reimplementing without klibc (whether or not we decide to use that branch) is definitely on my lis tof things to do. [09:38] So we'll see where that goes. [09:38] Right now, I should get back to making X build. === infinity shakes his fist at keybuk. [10:09] If yo ukeep fixing my bugs, I'll have to keep fixing Daniel's bugs, and the world will go all topsy-turvy! [10:12] who's bugs is daniels fixing? [10:13] See, that may be where it all falls apart. [10:14] and who is fixing my bugs? === pitti_ [n=pitti@195.227.105.180] has joined #ubuntu-boot [10:25] infinity: hmm, do we want firmware in the initramfs or not? [10:26] Keybuk: no, you don't [10:26] otherwise initramfs will explode [10:27] what if they want an nfsroot on a network card that needs firmware? [10:29] Keybuk: tough luck... some initramfs are already too big [10:29] and netboot on some machines is broken for that [10:38] Well, PXE on wireless is never going to happen, but do we have wired cards that require firmware to go? [10:39] only wireless [10:39] afaik [10:39] fabbione : firmware wouldn't explode the initramfs. Most firmware is way smaller than the driver it goes with. [10:40] infinity: we are already fighting with oversize.. we need to put initramfs on a heavy diet [10:40] But, if we only ship firmware for wireless, it's not much of a win to have it in the initramfs IMO. [10:40] fabbione : Putting it on a diet is as simple as changing the mode used to build it. It's undecided at the moment if we WANT to do that, though. [10:40] (The current mode has the advantage of being portable between hardware devices, whereas the smart detection modes mean if you chage your hardware, your system may not boot) [10:41] infinity: ppc can't netboot.. it has been decided already :) [10:41] starting from the amount of drivers will be in the udeb and so on... [10:54] Kamion: ping? [10:56] Kamion: (for your scrollback pleasure) ... could we nuke the d-i/base-config/debootstrap/whatever-does-it thing that adds /proc to /etc/fstab ... it's absolutely useless ;) [11:01] it's nice to be able to 'mount /proc' without having to remember the arguments [11:01] but file a bug on partman-target with rationale as to why it's actively bad to have it there [11:04] it's not so much actively bad, as misleading [11:04] it's never used by the main boot, so gives users the illusion that they can change it there and have some effect [11:04] and as /sys and /dev aren't alongside it, it looks strange [11:05] need to also check that stuff in d-i doesn't rely on it [11:05] (obviously it would be easy to change) === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-boot [01:24] Keybuk: wireless nfsroot will probably want firmware. [01:25] fabbione: ppc can suck raw eggs. =) What we did in Debian for initrd was to set ppc to dep and not the others. [01:26] dep? [01:26] dude.. i have a ppc [01:26] and i use netboot [01:27] initramfs must work [01:27] or i am going to make an offer this channel can't refure [01:27] refuse even [01:29] So set your initramfs generator to dep mode. [01:29] Just because that arch is broken doesn't mean the others need to be penalised against a very useful use case. [01:30] i still need to figure who does root over wireless [01:32] jbailey: please upload latest initramfs-tools :) [01:37] makx: I'd prefer in general that 'sync with ubuntu' contained some level of details. === jbailey builds. [01:38] It's not that important since Ubuntu is upstream for you. [01:38] But since that's the only changelog file, you're actually dropping information there. [01:39] There's no way to trace what's changed without a debdiff. [01:39] makx: Uploaded. [02:14] I'm confused, why can't ppc netboot? why does it have a maximum ramfs size? [02:15] Keybuk: for some reasons OF can't load a file bigger than 6MB via tftp [02:15] sounds like a bug that can be fixed [02:16] just load the initramfs in 6MB chunks [02:17] Keybuk: There seems to be a discussion about hostnames on the u-d. Didn't we solve this problem at ubz? [02:17] ISTR you or someone asking about it. [02:17] no? [02:17] wasn't me [02:17] Hmm [02:17] Colin's apparently enabled hostname now which makes it harder to get rid of busybox if we want to at some point. [02:18] do we want to get rid of busybox? [02:19] I don't. busybox is love. [02:19] in busybox vs. klibc-utils, I err towards busybox IF we can get it to stop forking for its built-ins :) [02:19] Jeff is a purist, however, who thinks that eventually we can implement the whole thing as ed scripts. === HiddenWolf [n=HiddenWo@136.76.dynamic.phpg.net] has joined #ubuntu-boot [02:20] Keybuk: My idealist version is that it should be possibly to disable it and get a 20k initramfs in dep mode. =) [02:20] possible, rather. [02:21] what shell would you use ? [02:21] and udev alone is about 150-200K [02:21] Is it that big now? [02:21] Hmm [02:21] Okay, 100k then. [02:21] initramfs' are gzip'd. [02:22] Keybuk: There's no reason for things in there not to be ash friendly. [02:22] udevd is 55K, udevplug is 28K [02:23] all of the little helpers are about 240K together [02:24] jbailey: harder to get rid of busybox> I don't understand how me enabling hostname makes it any harder? [02:24] and busybox' shell *is* ash, near enough [02:24] You jus tgave us one more crutch? [02:24] true [02:25] Not that I mind, terribly. [02:25] Keybuk: can we recognize ditital cameras by a device type argument, or do we need usermaps, just as with scanners? [02:26] Kamion: What he said. It's only an issue if there's still value in reducing the initramfs size by switching to really tiny utilities. [02:26] Kamion: My argument is that there is, based on the fact that reading things over the network in grub is suck, as is reading off of flash. [02:26] I'm not sure there is much value in trying to make it tiny. [02:27] Making it not HUGE is good, but I dunno how tiny it needs to be. [02:27] pitti: where there's a usermap now, there's probably a good reason [02:27] Poeple booting from network and flash don't do it often enough to care about a few extra seconds' boot time. [02:27] you can do class-matching with the existing usermaps [02:27] (At least, they shouldn't be) [02:27] so I figure if they could, they would have [02:27] infinity: Having an embedded device be usable in 5 to 10 seconds is good. Loading the current sized initramfs off of CF was reported to be in the 1 to 2 minute range. [02:28] Keybuk: ok, so I'm going to merge libgphoto2 for now (just wanted to ask whether it woudd be a complete waste) [02:28] jbailey : I'd argue that our bug lies elsewhere, then, that read speed is inexcusable. [02:29] infinity: Limitation of pc bios. No dma, sucky short reads. [02:29] That's why it's not a problem at runtime. [02:30] (And why are embedded device folk running Ubuntu kernels and bloated initrds anyway?) [02:31] pitti: I think we should keep both usermaps, we can support them for free; and only remove them if we're damned sure we can replace them for every device they use [02:32] infinity: CF != embedded in every case. [02:32] Keybuk: ok; Debian's libgphoto generates its own udev rules from the usermap ATM [02:32] infinity: It can be thinclient as well. [02:32] Keybuk: that certainly works, but we might be able to speed it up with grepmap [02:32] pitti: exactly, I think we should stick with the usermap simply because the conversion sucks [02:32] Keybuk: oh, it would be a conversion in the other way [02:33] how do you mean? [02:33] Keybuk: the former print-usb-usermap (which generated the usermap) now changed syntax to look like udev rules [02:33] Keybuk: of course we can revert to the older version for that [02:33] oh right, what's the source of that? [02:33] ie. where does it get the ids [02:33] jbailey : It could be, yes. I did thin clients with IDE-CF once. Of course, I also don't recall them being that shit-slow at loading kernels off the CF either, so... === Kamion wonders if there's any way to load i82365 or the other PCMCIA bridges using udev rules rather than an init script [02:34] for that one, it sounds like we should use the udev rules then -- call it /etc/udev/rules.d/85-gphoto.rules or something [02:34] yenta_socket should be handled automatically now [02:34] Kamion: is there an event you can load them on? [02:34] Keybuk: hard to tell - all my machines are yenta AFAIK [02:34] jbailey : Oh well. I can see that there are corner cases for tiny initrds, but I'm not sure it's a case I'm inclined to optimise for. People who really need a tiny boot can figure out how to make one. [02:34] (monolithic kernels, whatever) [02:35] hm, well, I could move the dodgy logic from pcmcia-cs' init script into a udev rule that gets called on pcmcia_socket add [02:35] Kamion: grep for them in modules.alias [02:35] Keybuk: I did; i82365 at least isn't there [02:35] infinity: I'm not arguing to optimse for that. Certainly I'm inclined to include busybox in every common case - I like having ls around if nothing else when I'm troubleshooting. [02:35] nor is tcic [02:36] infinity: But if there are reasonable things we can do (like poking the value into proc rather than using hostname) I think it's worth doing. [02:36] Kamion: a lot of the non-yenta bridges are ISA or equally antiquated, aren't they? [02:37] jbailey : Which one report claimed didn't work. [02:37] Keybuk: i82365 is ISA; I can't quite figure out what the hell tcic is, but it at least only does PCMCIA not Cardbus [02:38] i82092 is PCI [02:38] (and in modules.alias) [02:39] the ISA ones are a bitch, because there's no way to detect them except with a stick [02:39] and some machines (usually Dells) don't like being poked with a stick [02:41] Keybuk: sorry, got distracted; I think the conversion tool parses it out of the C source [02:41] pitti: ok, use the existing conversion tool then :) I thought you meant they had a tool to convert usermaps into udev.rules [02:41] so for gphoto, we should use udev.rules and write them to /etc/udev/rules.d/85-gphoto.rules [02:41] what does libsane do? [02:42] Keybuk: for gphoto that's exactly how Debian does it now [02:42] Keybuk: are the udev rules pre-parsed into memory structures, or are the text files parsed every time? [02:42] pre-parsed now [02:42] Keybuk: OTOH, udev parsing shouldn't be that much slower than grepmap, or is it? [02:42] note that the order matters, and our ordering is different to Debian's, so the filename might need to be different [02:42] Keybuk: pcmcia-cs already has a pcic_probe and /etc/default/pcmcia that you can frob if you need to; all I need to do is check /etc/default/pcmcia and load what it says to load, more or less [02:42] Kamion: ok, we could steal that I guess [02:43] yeah, I think what I'll do is write /lib/udev/pcmciautils that reads /etc/default/pcmcia and loads the module [02:43] jbailey: thanks! :) [02:43] and attach that to pcmcia_socket add [02:44] what adds pcmcia_socket ? [02:45] if the helper could output a list of modules, you can use a rule like: PROGRAM="/lib/udev/pcmciautils", RUN+="/sbin/modprobe $result" [02:45] and make the helper exit 1 if there aren't modules [02:45] that's then consistent with the other things that do exactly that === infinity [n=adconrad@loki.0c3.net] has left #ubuntu-boot [] [02:58] Keybuk: Debian uses udev rule symlink 25_* (gphoto); so 85 is ok for us? [02:58] 85-gphoto.rules file is what we should have [02:59] hmm [02:59] hang on [02:59] what do these rules do, just assign permissions? [02:59] can you paste one? [03:28] Keybuk: what adds pcmcia_socket> cs.c, I think, in an __init [03:29] right, so how does that get loaded? [04:04] pitti: so, yeah, paste a rule example couldya for gphoto? [04:04] Keybuk: I didn't continue the merge during the meeting, gimme some minutes [04:04] :( === infinity [n=adconrad@loki.0c3.net] has joined #ubuntu-boot [04:05] I guess I could just steal the debian package and peek [04:07] pitti: so, these rules are really sucky [04:07] could I suggest a _little_ tweak :) [04:07] Keybuk: it's part of pcmcia_core; good question exactly what loads that first [04:07] sure [04:07] right now it generates something that looks like ... [04:07] BUS!="usb", ACTION!="add", GOTO="libgphoto2_rules_end" [04:07] : rules here [04:07] for PCI systems it'll be coldplugged as usual, since the world depends on it [04:07] LABEL="libgphoto2_rules_end" [04:08] so that has a problem already [04:08] you can't do BUS!= :) [04:08] change that to be SUBSYSTEM!="usb_device" [04:08] then the rules themselves, they look like [04:08] BUS != 'usb' looks a bit odd anyway? [04:08] SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", RUN+="/etc/hotplug/usb/usbcam" [04:08] we have a 'modprobe pcmcia' in the pcmcia_socket add udev rule for ISA systems etc., but I'm not sure what would cause that rule to actually get called on such systems [04:08] pitti: it's skipping the rules for anything not a usb add event [04:08] I was hoping not to need an init script ... [04:09] ah, ok [04:09] and the script just assigns permissions to things [04:09] which is a bit doofus [04:09] so.... [04:09] could we change the output to be something like [04:09] set the permissoins right away, yes [04:09] SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end" [04:10] SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", GROUP="plugdev", MODE="0660" [04:10] LABEL="libgphoto2_rules_end" [04:10] yes, that looks better [04:10] (and yes, I deliberately dropped the ACTION!=add thing) [04:10] I'll modify print-udev-rules-bla.c accordingly [04:10] then write the file as /etc/udev/rules.d/45-gphoto.rules [04:10] (45 not 85 so it doesn't get included in initramfs) [04:10] ok, sure [04:11] the rule numbers are set up in such a way that 50-xxx is the perfect place for user rules ... 20 assigns names, 40 permissions, 60 symlinks, 80 runs programs and 90 runs modprobe [04:12] initramfs doesn't have permissions, symlinks or programs ... so gets 0-39 and 90+ === jbailey removes 'initramfs' from his nick highlight list. [04:14] now, I shall make tea [04:14] then I shall get my laptop booting again, after I foolishly forgot to put udev.conf in the initramfs [05:02] ok, I'm going to give pcmciautils an init script that does the bridge module probe if it needs to; I don't see a way to do this within udev [05:03] and I'll make it take a copy of /etc/default/pcmcia as /etc/default/pcmciautils so that I don't have to deal with pcmcia-cs.postrm removing the former [05:03] yeah, I don't think there is a way to do it with udev [05:04] udev reacts to events, if there's no event to react to, there's no way to do it [05:04] udev will correctly react to the modprobe, of course, so all you need to do is _start_ it [05:04] for most devices, the thing that starts stuff is udevplug, which walks sysfs and tickles everything the kernel's found so far [05:05] but if the kernel hasn't found legacy pcmcia buses, there needs to be a manual stick [05:05] all the init script does is modprobe pcmcia_core, then if there's no /sys/class/pcmcia_socket/* yet modprobe $PCIC [05:05] basically [05:05] I thought all of the pccard love was supposed to just get folded in so that it behaved the same as any other pluggable bus (usb, ieee1394, etc..) [05:05] jbailey: it does, but only for PCI bridges [05:05] jbailey: it has been [05:05] then once the bridge is up, the rest is a regular hotpluggable bus [05:05] jbailey: you still need something to modprobe the drivers for the old ISA pcmcia bridges though [05:05] Ah, okay. [05:06] Kamion: ok ... beware that the /sys thing won't turn up straight away [05:06] Keybuk: no harm done if it doesn't, I think; I've stolen the code from pcmcia-cs.init to check whether there's a yenta bridge there by poking in /sys/bus/pci/devices/*/class [05:06] right [05:06] and fixed it to detect i82092 as well, which is the only other PCI bridge I can see [05:07] that stuff's probably needless now [05:07] if there's a /sys/bus/pci/devices/*/class that's a yenta bridge, then yenta_socket will be loaded [05:07] yeah, just a sanity-check to make sure we don't accidentally probe the wrong bridge [05:07] and you'll have /sys/bus/pcmcia [05:07] *nods* [05:08] because apparently /etc/default/pcmcia is sometimes broken on old upgrades and says i82365 when it isn't [05:08] and we check /sys/class/pcmcia_socket/* before any of this too, so if boot-time events loaded the bridge then none of this will happen anyway [05:08] ok, fixed udevplug bug, time for manual boot #3 [05:10] ugh @ /sbin/udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 /class/mem /class/misc /class/tty /class/vc /block [05:10] I'm so aliasing that to /sbin/udevplug --whatever-initramfs-needs [05:12] anyone know what the serio, eisa or MCA buses are? [05:15] eisa is/was a competitor to ps/2 [05:15] eisa was an extended isa bus. [05:15] Supported some autoconfiguration, and a slightly wider bus path. [05:15] The sockets could also take isa cards. [05:15] jbailey: anything on any of those we might need for initramfs? [05:15] ie. storage or hid controllers? [05:15] hm [05:15] Keybuk: EISA *might* actually be autodetectable enough for initramfs. [05:16] /sys/bus/eisa/devices is empty on my system (at least on initial startup) [05:16] It was somewhat expensive to implement (though not as much as MCA), so it never became particularly popular in desktop PCs. However, it was reasonably successful in the server market, [05:16] On a truly ancient system, yeah. It was a good way of actually getting harddrive controllers in. I think my alpha has eisa. But it was popular in servers (and freaking expensive) [05:16] /sys/bus/MCA has turned up in 2.6.15 ... I think it wants to shout [05:17] MCA is overloaded. [05:17] Clasic MCA was a PS/2 architecture with autodetection. [05:17] I'll leave them out until someone bitches [05:17] I think it's now something else. [05:17] we're already poking enough as it is [05:18] I maintainer my argument that we don't actually care about anything pre-PCI for booting. =) [05:18] maintain, rather =) [05:18] Anything that old won't run gnome in any useful way. [05:18] what's i2o? [05:18] you put that in the spec when I wasn't looking [05:18] It's a bus standard that was suppose to feature standarized drivers for high end hardware. [05:19] I've never actually had one. Tollef has, though. [05:19] does it have root filesystems on it? [05:19] It does on his box. [05:19] initramfs-tools theoretically supports it in Breezy. [05:19] ok [05:19] # /sbin/udevplug -Bide [05:19] udevplug[4499] : scan_bus: unable to open bus 'ide' [05:19] \o/ [05:20] same thing for scsi, i2o, usb and ieee1394 [05:21] (those bits are only for compile-your-own idiots ... those buses should be missing at this point, as we haven't probed the pci bus for storage controllers yet) [05:21] hmm, is it really /sys/bus/ieee1394 ? I haven't got one [05:21] jbailey@starshine:/sys/bus$ ls [05:21] i2c ide ieee1394 macio of_platform pci pcmcia platform scsi usb vio [05:22] i2c ? is that different to i2o? [05:22] macio? vio? WHO INVENTED ALL THESE THINGS?! :) [05:22] my laptop has a /sys/bus/pci_express ... wonder whether we should look for controllers on that [05:23] I think i2c is different, yes. [05:23] I don't know how, though. [05:23] jbailey@starshine:/sys/bus/i2c/drivers$ ls [05:23] i2c_adapter PMac Keywest Audio therm_pm72 [05:23] I2C (pronounce: I squared C) is a protocol developed by Philips. It is a [05:23] slow two-wire protocol (10-400 kHz), but it suffices for many types of [05:23] devices. [05:23] oh [05:24] it's the fan-speed thing [05:24] Keybuk: hey, look at that nice rule: [05:24] macio and vio are similar-ish I think - at least, vio uses /proc/device-tree too [05:24] # USB PTP Class Camera [05:24] SYSFS{bDeviceClass}=="06", GROUP="plugdev", MODE="0660" [05:24] Keybuk: ^ *that*'s what rules should look like :) [05:25] pitti: yeah, that one should work for a lot of things -- provided it's within a SUBSYSTEM!="usb_device", GOTO="..." thing [05:25] Keybuk: fan speed, some Mac sound devices, random other stuff on Macs too [05:25] Keybuk: yes, it is, I did the conversion [05:25] kewl [05:25] right, now for the biiig test [05:26] crw-rw---- 1 root plugdev 189, 260 2005-11-24 17:25 /dev/usbdev3.5 [05:26] does /sbin/udevplug -Bpci -Iclass=0x010[01] * do the right thing? [05:26] hmm [05:27] that caused ide_core, alim15x3 and generic to be loaded [05:27] but, pointedly, no /dev/hda to appear [05:27] grr [05:27] Keybuk: now I'll try to convince libgphoto to actually talk to /dev/usbdev3.5 instead of /proc/bus/usb/003/004 [05:27] s/4$/5/ [05:28] pitti: it'll be /dev/bus/usb/003/004 with our naming rules [05:28] so you should just replace /proc with /dev [05:29] Keybuk: oh, ok, right now it's like above [05:29] but if that works in general, that should be fine [05:31] yeah, that's the "kernel-assigned" name for those devices [05:31] which is a bit boring [05:32] hmm [05:32] ok [05:32] /dev/hda, oh /dev/hda, wherefor art thou /dev/hda? [05:35] jbailey: ok, I'm clearly being stupid ... what provides those devices? [05:36] Keybuk: Eh? It's in /sys/block [05:36] What do you mean by what provides? [05:36] well [05:36] what module do I need to load? [05:36] they're not in /sys/block yet, because I haven't loaded the right module [05:38] Oh [05:38] your specific ide module [05:38] ide-disk [05:39] ide-generic [05:39] ok... so how do I know to load ide-disk? :P [05:39] ide-generic must be last. [05:39] You have to walk /proc/ide to get the info on each device. [05:39] no devices there yet ... you see [05:40] just /proc/ide/drivers [05:40] ohhh [05:40] I see the problem [05:40] Right, but when you load cmd64x or whatever. [05:40] wtf is "generic" [05:40] It'll be there. [05:40] not "ide-generic", "generic" [05:40] Did they rename it? [05:40] no... [05:40] And ide-generic doesn't have to be last, sorry, just has to be after any specific IDE drivers you want. [05:40] But then /proc/ide will exist. [05:41] generic is what got loaded (along with ide-core and the specific module) when I walked the PCI bus [05:41] not ide-generic [05:41] Ah. [05:41] No idea what "generic" is. [05:41] description=PCI driver module for generic PCI IDE [05:42] right, very odd [05:42] ok, so I need a rule in here somewhere to load ide-generic ... wonder how I'm going to shimmy that [05:57] Keybuk: how practical - our current libusb already checks for /dev/bus/usb before /proc/bus/usb :) [05:57] Keybuk: so I only need to teach it about /dev/usbdevX.Y [05:57] ok, that's pcmciautils updated; the only thing I think pcmcia-cs is needed for now is setting up the resource database on installation, and possibly some CIS bits [05:57] I'll look at those later [05:58] pitti: you probably don't need to do that [05:58] nobody is shipping without the /dev/bus/usb rules that I'm aware of [05:58] Keybuk: I could wait with the gphoto upload until you upload udev [05:58] Keybuk: we do at the moment :) [05:58] well, no, we don't TECHNICALLY :p [05:59] yeah, I'd wait and not support usbdevX.Y [05:59] hmm [05:59] Keybuk: ok, for testing I just modify my local udev rules, I guess [05:59] didn't we blacklist all of the framebuffer devices? [06:00] ahh [06:00] no [06:00] the old hotplug pci.agent just skipped them [06:00] hmm [06:00] udevplug doesn't do that, of course [06:01] I wonder whether there's some modprobe.d trick we can use to blacklist an entire class [06:03] Keybuk: yay, a symlink works nicely, great; thanks for your help [06:04]