[08:33] <fabbione> Keybuk: you got your ubuntulog
[08:33] <Keybuk> thanks
[08:34] <fabbione> Keybuk: anyway the best is to just send me a mail
[08:35] <fabbione> becuase the bot is like -20 in my priority list :)
[08:35] <Keybuk> is that nice -20, or ... ? :p
[08:36] <fabbione> ehhe
[09:12] <Keybuk> 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] <makx> ubuntu is behind atm.
[09:23] <Keybuk> fsvo "behind"
[09:23] <Keybuk> all the changes in your 039 are irrelevant for ubuntu
[09:23] <makx> we have changes jbailey ok'ed but didn't want to push yet for breezy
[09:24] <Keybuk> and replaced by those in our 040, which won't work for Debian
[09:24] <Keybuk> (or whatever version we use for it)
[09:24] <infinity> 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] <infinity> So, pick a version number at random, and make sure it has "ubuntu" in the name, and we'll sort it later. :/
[09:24] <Keybuk> infinity: ok
[09:25] <infinity> So, hurry the heck up. :)
[09:25] <Keybuk> am doing my changes right now :)  so the lock will be released once these are done and uploaded
[09:26] <makx> you still don't have a manpage for update-initramfs
[09:26] <Keybuk> 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] <makx> Keybuk: yes
[09:27] <makx> we already have an hooks/udev
[09:28] <makx> inifinity: please tell what is utter crack?
[09:28] <infinity> Keybuk : That would be beyond fine.
[09:28] <infinity> Keybuk : In fact, that's what we SHOULD be doing.
[09:28] <infinity> Keybuk : The less package-specific cruft we have in initramfs, the better.
[09:29] <infinity> Keybuk : If that approach can be done in both Debian and Ubuntu, our diffs may get very small again.
[09:29] <Keybuk> ok, because scripts/init-top/udev makes a lot of sense to me
[09:29] <Keybuk> along with hooks/udev to copy over things
[09:29] <infinity> (Which is one motivation for making it work that way)
[09:29] <Keybuk> and ship those in udev itself, rather than in initramfs-tools
[09:30] <infinity> makx : Nothing is "utter crack" so much as stuff that should be discussed.  I was being overly dramatic for effect. :)
[09:30] <infinity> Keybuk : Yes please.
[09:31] <makx> infinity: evms will move to it's package what else is bad?
[09:31] <infinity> evms was one, yes.
[09:31] <infinity> 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] <infinity> The more initramfs is kept as a flexible framework with very little actual "content", the better.
[09:32] <Keybuk> 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] <infinity> I'm also wondering at what stage we should declare klibc a failed experiment, and just use glibc everywhere.
[09:33] <makx> do we have everything in busybox?
[09:33] <Keybuk> infinity: the klibc utilities are useful, but that's it
[09:33] <infinity> Keybuk : What does klibc ship that we couldn't get from turning on some busybox options?
[09:34] <infinity> (or building a few tiny binaries of our own, linked against glibc)
[09:34] <makx> would help a lot on Debian, klibc isn't ready for quite some archs
[09:35] <Keybuk> infinity: no idea, the binaries that come with klibc are tiny
[09:35] <Keybuk> we could just copy anything there we didn't have in busybox
[09:35] <Keybuk> run-init is probably the main one ;)
[09:38] <infinity> Reimplementing without klibc (whether or not we decide to use that branch) is definitely on my lis tof things to do.
[09:38] <infinity> So we'll see where that goes.
[09:38] <infinity> Right now, I should get back to making X build.
[10:09] <infinity> 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] <Keybuk> who's bugs is daniels fixing?
[10:13] <infinity> See, that may be where it all falls apart.
[10:14] <Keybuk> and who is fixing my bugs?
[10:25] <Keybuk> infinity: hmm, do we want firmware in the initramfs or not?
[10:26] <fabbione> Keybuk: no, you don't
[10:26] <fabbione> otherwise initramfs will explode
[10:27] <Keybuk> what if they want an nfsroot on a network card that needs firmware?
[10:29] <fabbione> Keybuk: tough luck... some initramfs are already too big
[10:29] <fabbione> and netboot on some machines is broken for that
[10:38] <infinity> Well, PXE on wireless is never going to happen, but do we have wired cards that require firmware to go?
[10:39] <fabbione> only wireless
[10:39] <fabbione> afaik
[10:39] <infinity> fabbione : firmware wouldn't explode the initramfs.  Most firmware is way smaller than the driver it goes with.
[10:40] <fabbione> infinity: we are already fighting with oversize.. we need to put initramfs on a heavy diet
[10:40] <infinity> But, if we only ship firmware for wireless, it's not much of a win to have it in the initramfs IMO.
[10:40] <infinity> 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] <infinity> (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] <fabbione> infinity: ppc can't netboot.. it has been decided already :)
[10:41] <fabbione> starting from the amount of drivers will be in the udeb and so on...
[10:54] <Keybuk> Kamion: ping?
[10:56] <Keybuk> 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] <Kamion> it's nice to be able to 'mount /proc' without having to remember the arguments
[11:01] <Kamion> but file a bug on partman-target with rationale as to why it's actively bad to have it there
[11:04] <Keybuk> it's not so much actively bad, as misleading
[11:04] <Keybuk> 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] <Keybuk> and as /sys and /dev aren't alongside it, it looks strange
[11:05] <Kamion> need to also check that stuff in d-i doesn't rely on it
[11:05] <Kamion> (obviously it would be easy to change)
[01:24] <jbailey> Keybuk: wireless nfsroot will probably want firmware.
[01:25] <jbailey> 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] <fabbione> dep?
[01:26] <fabbione> dude.. i have a ppc
[01:26] <fabbione> and i use netboot
[01:27] <fabbione> initramfs must work
[01:27] <fabbione> or i am going to make an offer this channel can't refure
[01:27] <fabbione> refuse even
[01:29] <jbailey> So set your initramfs generator to dep mode.
[01:29] <jbailey> Just because that arch is broken doesn't mean the others need to be penalised against a very useful use case.
[01:30] <fabbione> i still need to figure who does root over wireless
[01:32] <makx> jbailey: please upload latest initramfs-tools :)
[01:37] <jbailey> makx: I'd prefer in general that 'sync with ubuntu' contained some level of details.
[01:38] <jbailey> It's not that important since Ubuntu is upstream for you.
[01:38] <jbailey> But since that's the only changelog file, you're actually dropping information there.
[01:39] <jbailey> There's no way to trace what's changed without a debdiff.
[01:39] <jbailey> makx: Uploaded.
[02:14] <Keybuk> I'm confused, why can't ppc netboot?  why does it have a maximum ramfs size?
[02:15] <fabbione> Keybuk: for some reasons OF can't load a file bigger than 6MB via tftp
[02:15] <Keybuk> sounds like a bug that can be fixed
[02:16] <Keybuk> just load the initramfs in 6MB chunks
[02:17] <jbailey> Keybuk: There seems to be a discussion about hostnames on the u-d.  Didn't we solve this problem at ubz?
[02:17] <jbailey> ISTR you or someone asking about it.
[02:17] <Keybuk> no?
[02:17] <Keybuk> wasn't me
[02:17] <jbailey> Hmm
[02:17] <jbailey> Colin's apparently enabled hostname now which makes it harder to get rid of busybox if we want to at some point.
[02:18] <Keybuk> do we want to get rid of busybox?
[02:19] <infinity> I don't.  busybox is love.
[02:19] <Keybuk> in busybox vs. klibc-utils, I err towards busybox IF we can get it to stop forking for its built-ins :)
[02:19] <infinity> Jeff is a purist, however, who thinks that eventually we can implement the whole thing as ed scripts.
[02:20] <jbailey> Keybuk: My idealist version is that it should be possibly to disable it and get a 20k initramfs in dep mode. =)
[02:20] <jbailey> possible, rather.
[02:21] <Keybuk> what shell would you use ?
[02:21] <Keybuk> and udev alone is about 150-200K
[02:21] <jbailey> Is it that big now?
[02:21] <jbailey> Hmm
[02:21] <jbailey> Okay, 100k then.
[02:21] <jbailey> initramfs' are gzip'd.
[02:22] <jbailey> Keybuk: There's no reason for things in there not to be ash friendly.
[02:22] <Keybuk> udevd is 55K, udevplug is 28K
[02:23] <Keybuk> all of the little helpers are about 240K together
[02:24] <Kamion> jbailey: harder to get rid of busybox> I don't understand how me enabling hostname makes it any harder?
[02:24] <Kamion> and busybox' shell *is* ash, near enough
[02:24] <infinity> You jus tgave us one more crutch?
[02:24] <Kamion> true
[02:25] <infinity> Not that I mind, terribly.
[02:25] <pitti> Keybuk: can we recognize ditital cameras by a device type argument, or do we need usermaps, just as with scanners?
[02:26] <jbailey> 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] <jbailey> 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] <infinity> I'm not sure there is much value in trying to make it tiny.
[02:27] <infinity> Making it not HUGE is good, but I dunno how tiny it needs to be.
[02:27] <Keybuk> pitti: where there's a usermap now, there's probably a good reason
[02:27] <infinity> Poeple booting from network and flash don't do it often enough to care about a few extra seconds' boot time.
[02:27] <Keybuk> you can do class-matching with the existing usermaps
[02:27] <infinity> (At least, they shouldn't be)
[02:27] <Keybuk> so I figure if they could, they would have
[02:27] <jbailey> 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] <pitti> Keybuk: ok, so I'm going to merge libgphoto2 for now (just wanted to ask whether it woudd be a complete waste)
[02:28] <infinity> jbailey : I'd argue that our bug lies elsewhere, then, that read speed is inexcusable.
[02:29] <jbailey> infinity: Limitation of pc bios.  No dma, sucky short reads.
[02:29] <jbailey> That's why it's not a problem at runtime.
[02:30] <infinity> (And why are embedded device folk running Ubuntu kernels and bloated initrds anyway?)
[02:31] <Keybuk> 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] <jbailey> infinity: CF != embedded in every case.
[02:32] <pitti> Keybuk: ok; Debian's libgphoto generates its own udev rules from the usermap ATM
[02:32] <jbailey> infinity: It can be thinclient as well.
[02:32] <pitti> Keybuk: that certainly works, but we might be able to speed it up with grepmap
[02:32] <Keybuk> pitti: exactly, I think we should stick with the usermap simply because the conversion sucks
[02:32] <pitti> Keybuk: oh, it would be a conversion in the other way
[02:33] <Keybuk> how do you mean?
[02:33] <pitti> Keybuk: the former print-usb-usermap (which generated the usermap) now changed syntax to look like udev rules
[02:33] <pitti> Keybuk: of course we can revert to the older version for that
[02:33] <Keybuk> oh right, what's the source of that?
[02:33] <Keybuk> ie. where does it get the ids
[02:33] <infinity> 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...
[02:34] <Keybuk> 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] <Kamion> yenta_socket should be handled automatically now
[02:34] <Keybuk> Kamion: is there an event you can load them on?
[02:34] <Kamion> Keybuk: hard to tell - all my machines are yenta AFAIK
[02:34] <infinity> 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] <infinity> (monolithic kernels, whatever)
[02:35] <Kamion> 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] <Keybuk> Kamion: grep for them in modules.alias
[02:35] <Kamion> Keybuk: I did; i82365 at least isn't there
[02:35] <jbailey> 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] <Kamion> nor is tcic
[02:36] <jbailey> 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] <Keybuk> Kamion: a lot of the non-yenta bridges are ISA or equally antiquated, aren't they?
[02:37] <infinity> jbailey : Which one report claimed didn't work.
[02:37] <Kamion> 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] <Kamion> i82092 is PCI
[02:38] <Kamion> (and in modules.alias)
[02:39] <Keybuk> the ISA ones are a bitch, because there's no way to detect them except with a stick
[02:39] <Keybuk> and some machines (usually Dells) don't like being poked with a stick
[02:41] <pitti> Keybuk: sorry, got distracted; I think the conversion tool parses it out of the C source
[02:41] <Keybuk> pitti: ok, use the existing conversion tool then :)  I thought you meant they had a tool to convert usermaps into udev.rules
[02:41] <Keybuk> so for gphoto, we should use udev.rules and write them to /etc/udev/rules.d/85-gphoto.rules
[02:41] <Keybuk> what does libsane do?
[02:42] <pitti> Keybuk: for gphoto that's exactly how Debian does it now
[02:42] <pitti> Keybuk: are the udev rules pre-parsed into memory structures, or are the text files parsed every time?
[02:42] <Keybuk> pre-parsed now
[02:42] <pitti> Keybuk: OTOH, udev parsing shouldn't be that much slower than grepmap, or is it?
[02:42] <Keybuk> note that the order matters, and our ordering is different to Debian's, so the filename might need to be different
[02:42] <Kamion> 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] <Keybuk> Kamion: ok, we could steal that I guess
[02:43] <Kamion> yeah, I think what I'll do is write /lib/udev/pcmciautils that reads /etc/default/pcmcia and loads the module
[02:43] <makx> jbailey: thanks! :)
[02:43] <Kamion> and attach that to pcmcia_socket add
[02:44] <Keybuk> what adds pcmcia_socket ?
[02:45] <Keybuk> 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] <Keybuk> and make the helper exit 1 if there aren't modules
[02:45] <Keybuk> that's then consistent with the other things that do exactly that
[02:58] <pitti> Keybuk: Debian uses udev rule symlink 25_* (gphoto); so 85 is ok for us?
[02:58] <Keybuk> 85-gphoto.rules file is what we should have
[02:59] <Keybuk> hmm
[02:59] <Keybuk> hang on
[02:59] <Keybuk> what do these rules do, just assign permissions?
[02:59] <Keybuk> can you paste one?
[03:28] <Kamion> Keybuk: what adds pcmcia_socket> cs.c, I think, in an __init
[03:29] <Keybuk> right, so how does that get loaded?
[04:04] <Keybuk> pitti: so, yeah, paste a rule example couldya for gphoto?
[04:04] <pitti> Keybuk: I didn't continue the merge during the meeting, gimme some minutes
[04:04] <Keybuk> :(
[04:05] <Keybuk> I guess I could just steal the debian package and peek <g>
[04:07] <Keybuk> pitti: so, these rules are really sucky
[04:07] <Keybuk> could I suggest a _little_ tweak :)
[04:07] <Kamion> Keybuk: it's part of pcmcia_core; good question exactly what loads that first
[04:07] <pitti> sure
[04:07] <Keybuk> right now it generates something that looks like ...
[04:07] <Keybuk> BUS!="usb", ACTION!="add", GOTO="libgphoto2_rules_end"
[04:07] <Keybuk>   : rules here
[04:07] <Kamion> for PCI systems it'll be coldplugged as usual, since the world depends on it
[04:07] <Keybuk> LABEL="libgphoto2_rules_end"
[04:08] <Keybuk> so that has a problem already
[04:08] <Keybuk> you can't do BUS!= :)
[04:08] <Keybuk> change that to be SUBSYSTEM!="usb_device"
[04:08] <Keybuk> then the rules themselves, they look like
[04:08] <pitti> BUS != 'usb' looks a bit odd anyway?
[04:08] <Keybuk> SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", RUN+="/etc/hotplug/usb/usbcam"
[04:08] <Kamion> 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] <Keybuk> pitti: it's skipping the rules for anything not a usb add event
[04:08] <Kamion> I was hoping not to need an init script ...
[04:09] <pitti> ah, ok
[04:09] <Keybuk> and the script just assigns permissions to things
[04:09] <Keybuk> which is a bit doofus
[04:09] <Keybuk> so....
[04:09] <Keybuk> could we change the output to be something like
[04:09] <pitti> set the permissoins right away, yes
[04:09] <Keybuk> SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end"
[04:10] <Keybuk> SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", GROUP="plugdev", MODE="0660"
[04:10] <Keybuk> LABEL="libgphoto2_rules_end"
[04:10] <pitti> yes, that looks better
[04:10] <Keybuk> (and yes, I deliberately dropped the ACTION!=add thing)
[04:10] <pitti> I'll modify print-udev-rules-bla.c accordingly
[04:10] <Keybuk> then write the file as /etc/udev/rules.d/45-gphoto.rules
[04:10] <Keybuk> (45 not 85 so it doesn't get included in initramfs)
[04:10] <pitti> ok, sure
[04:11] <Keybuk> 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] <Keybuk> initramfs doesn't have permissions, symlinks or programs ... so gets 0-39 and 90+
[04:14] <Keybuk> now, I shall make tea
[04:14] <Keybuk> then I shall get my laptop booting again, after I foolishly forgot to put udev.conf in the initramfs <g>
[05:02] <Kamion> 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] <Kamion> 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] <Keybuk> yeah, I don't think there is a way to do it with udev
[05:04] <Keybuk> udev reacts to events, if there's no event to react to, there's no way to do it
[05:04] <Keybuk> udev will correctly react to the modprobe, of course, so all you need to do is _start_ it
[05:04] <Keybuk> for most devices, the thing that starts stuff is udevplug, which walks sysfs and tickles everything the kernel's found so far
[05:05] <Keybuk> but if the kernel hasn't found legacy pcmcia buses, there needs to be a manual stick
[05:05] <Kamion> all the init script does is modprobe pcmcia_core, then if there's no /sys/class/pcmcia_socket/* yet modprobe $PCIC
[05:05] <Kamion> basically
[05:05] <jbailey> 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] <Kamion> jbailey: it does, but only for PCI bridges
[05:05] <Keybuk> jbailey: it has been
[05:05] <Kamion> then once the bridge is up, the rest is a regular hotpluggable bus
[05:05] <Keybuk> jbailey: you still need something to modprobe the drivers for the old ISA pcmcia bridges though
[05:05] <jbailey> Ah, okay.
[05:06] <Keybuk> Kamion: ok ... beware that the /sys thing won't turn up straight away
[05:06] <Kamion> 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] <Keybuk> right
[05:06] <Kamion> and fixed it to detect i82092 as well, which is the only other PCI bridge I can see
[05:07] <Keybuk> that stuff's probably needless now
[05:07] <Keybuk> if there's a /sys/bus/pci/devices/*/class that's a yenta bridge, then yenta_socket will be loaded
[05:07] <Kamion> yeah, just a sanity-check to make sure we don't accidentally probe the wrong bridge
[05:07] <Keybuk> and you'll have /sys/bus/pcmcia
[05:07] <Keybuk> *nods*
[05:08] <Kamion> because apparently /etc/default/pcmcia is sometimes broken on old upgrades and says i82365 when it isn't
[05:08] <Kamion> 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] <Keybuk> ok, fixed udevplug bug, time for manual boot #3
[05:10] <Keybuk> ugh @ /sbin/udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 /class/mem /class/misc /class/tty /class/vc /block
[05:10] <Keybuk> I'm so aliasing that to /sbin/udevplug --whatever-initramfs-needs
[05:12] <Keybuk> anyone know what the serio, eisa or MCA buses are?
[05:15] <HiddenWolf> eisa is/was a competitor to ps/2
[05:15] <jbailey> eisa was an extended isa bus.
[05:15] <jbailey> Supported some autoconfiguration, and a slightly wider bus path.
[05:15] <jbailey> The sockets could also take isa cards.
[05:15] <Keybuk> jbailey: anything on any of those we might need for initramfs?
[05:15] <Keybuk> ie. storage or hid controllers?
[05:15] <HiddenWolf> hm
[05:15] <jbailey> Keybuk: EISA *might* actually be autodetectable enough for initramfs.
[05:16] <Keybuk> /sys/bus/eisa/devices is empty on my system (at least on initial startup)
[05:16] <HiddenWolf> 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] <jbailey> 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] <Keybuk> /sys/bus/MCA has turned up in 2.6.15 ... I think it wants to shout
[05:17] <jbailey> MCA is overloaded.
[05:17] <jbailey> Clasic MCA was a PS/2 architecture with autodetection.
[05:17] <Keybuk> I'll leave them out until someone bitches
[05:17] <jbailey> I think it's now something else.
[05:17] <Keybuk> we're already poking enough as it is
[05:18] <jbailey> I maintainer my argument that we don't actually care about anything pre-PCI for booting. =)
[05:18] <jbailey> maintain, rather =)
[05:18] <jbailey> Anything that old won't run gnome in any useful way.
[05:18] <Keybuk> what's i2o?
[05:18] <Keybuk> you put that in the spec when I wasn't looking
[05:18] <jbailey> It's a bus standard that was suppose to feature standarized drivers for high end hardware.
[05:19] <jbailey> I've never actually had one.  Tollef has, though.
[05:19] <Keybuk> does it have root filesystems on it?
[05:19] <jbailey> It does on his box.
[05:19] <jbailey> initramfs-tools theoretically supports it in Breezy.
[05:19] <Keybuk> ok
[05:19] <Keybuk> # /sbin/udevplug -Bide
[05:19] <Keybuk> udevplug[4499] : scan_bus: unable to open bus 'ide'
[05:19] <Keybuk> \o/
[05:20] <Keybuk> same thing for scsi, i2o, usb and ieee1394
[05:21] <Keybuk> (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] <Keybuk> hmm, is it really /sys/bus/ieee1394 ?  I haven't got one
[05:21] <jbailey> jbailey@starshine:/sys/bus$ ls
[05:21] <jbailey> i2c  ide  ieee1394  macio  of_platform  pci  pcmcia  platform  scsi  usb  vio
[05:22] <Keybuk> i2c ?  is that different to i2o?
[05:22] <Keybuk> macio?  vio?  WHO INVENTED ALL THESE THINGS?! :)
[05:22] <Keybuk> my laptop has a /sys/bus/pci_express ... wonder whether we should look for controllers on that
[05:23] <jbailey> I think i2c is different, yes.
[05:23] <jbailey> I don't know how, though.
[05:23] <jbailey> jbailey@starshine:/sys/bus/i2c/drivers$ ls
[05:23] <jbailey> i2c_adapter  PMac Keywest Audio  therm_pm72
[05:23] <Keybuk> I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
[05:23] <Keybuk> slow two-wire protocol (10-400 kHz), but it suffices for many types of
[05:23] <Keybuk> devices.
[05:23] <Keybuk> oh
[05:24] <Keybuk> it's the fan-speed thing
[05:24] <pitti> Keybuk: hey, look at that nice rule:
[05:24] <Kamion> macio and vio are similar-ish I think - at least, vio uses /proc/device-tree too
[05:24] <pitti> # USB PTP Class Camera
[05:24] <pitti> SYSFS{bDeviceClass}=="06", GROUP="plugdev", MODE="0660"
[05:24] <pitti> Keybuk: ^ *that*'s what rules should look like :)
[05:25] <Keybuk> pitti: yeah, that one should work for a lot of things -- provided it's within a SUBSYSTEM!="usb_device", GOTO="..." thing
[05:25] <Kamion> Keybuk: fan speed, some Mac sound devices, random other stuff on Macs too
[05:25] <pitti> Keybuk: yes, it is, I did the conversion
[05:25] <Keybuk> kewl
[05:25] <Keybuk> right, now for the biiig test
[05:26] <pitti> crw-rw---- 1 root plugdev 189, 260 2005-11-24 17:25 /dev/usbdev3.5
[05:26] <Keybuk> does /sbin/udevplug -Bpci -Iclass=0x010[01] * do the right thing?
[05:26] <Keybuk> hmm
[05:27] <Keybuk> that caused ide_core, alim15x3 and generic to be loaded
[05:27] <Keybuk> but, pointedly, no /dev/hda to appear
[05:27] <Keybuk> grr
[05:27] <pitti> Keybuk: now I'll try to convince libgphoto to actually talk to /dev/usbdev3.5 instead of /proc/bus/usb/003/004
[05:27] <pitti> s/4$/5/
[05:28] <Keybuk> pitti: it'll be /dev/bus/usb/003/004 with our naming rules
[05:28] <Keybuk> so you should just replace /proc with /dev
[05:29] <pitti> Keybuk: oh, ok, right now it's like above
[05:29] <pitti> but if that works in general, that should be fine
[05:31] <Keybuk> yeah, that's the "kernel-assigned" name for those devices
[05:31] <Keybuk> which is a bit boring
[05:32] <Keybuk> hmm
[05:32] <Keybuk> ok
[05:32] <Keybuk> /dev/hda, oh /dev/hda, wherefor art thou /dev/hda?
[05:35] <Keybuk> jbailey: ok, I'm clearly being stupid ... what provides those devices?
[05:36] <jbailey> Keybuk: Eh? It's in /sys/block
[05:36] <jbailey> What do you mean by what provides?
[05:36] <Keybuk> well
[05:36] <Keybuk> what module do I need to load?
[05:36] <Keybuk> they're not in /sys/block yet, because I haven't loaded the right module
[05:38] <jbailey> Oh
[05:38] <jbailey> your specific ide module
[05:38] <jbailey> ide-disk
[05:39] <jbailey> ide-generic
[05:39] <Keybuk> ok... so how do I know to load ide-disk? :P
[05:39] <jbailey> ide-generic must be last.
[05:39] <jbailey> You have to walk /proc/ide to get the info on each device.
[05:39] <Keybuk> no devices there yet ... you see
[05:40] <Keybuk> just /proc/ide/drivers
[05:40] <Keybuk> ohhh
[05:40] <Keybuk> I see the problem
[05:40] <jbailey> Right, but when you load cmd64x or whatever.
[05:40] <Keybuk> wtf is "generic"
[05:40] <jbailey> It'll be there.
[05:40] <Keybuk> not "ide-generic", "generic"
[05:40] <jbailey> Did they rename it?
[05:40] <Keybuk> no...
[05:40] <jbailey> And ide-generic doesn't have to be last, sorry, just has to be after any specific IDE drivers you want.
[05:40] <jbailey> But then /proc/ide will exist.
[05:41] <Keybuk> generic is what got loaded (along with ide-core and the specific module) when I walked the PCI bus
[05:41] <Keybuk> not ide-generic
[05:41] <jbailey> Ah.
[05:41] <jbailey> No idea what "generic" is.
[05:41] <jbailey> description=PCI driver module for generic PCI IDE
[05:42] <Keybuk> right, very odd
[05:42] <Keybuk> ok, so I need a rule in here somewhere to load ide-generic ... wonder how I'm going to shimmy that
[05:57] <pitti> Keybuk: how practical - our current libusb already checks for /dev/bus/usb before /proc/bus/usb :)
[05:57] <pitti> Keybuk: so I only need to teach it about /dev/usbdevX.Y
[05:57] <Kamion> 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] <Kamion> I'll look at those later
[05:58] <Keybuk> pitti: you probably don't need to do that
[05:58] <Keybuk> nobody is shipping without the /dev/bus/usb rules that I'm aware of
[05:58] <pitti> Keybuk: I could wait with the gphoto upload until you upload udev
[05:58] <pitti> Keybuk: we do at the moment :)
[05:58] <Keybuk> well, no, we don't TECHNICALLY :p
[05:59] <Keybuk> yeah, I'd wait and not support usbdevX.Y
[05:59] <Keybuk> hmm
[05:59] <pitti> Keybuk: ok, for testing I just modify my local udev rules, I guess
[05:59] <Keybuk> didn't we blacklist all of the framebuffer devices?
[06:00] <Keybuk> ahh
[06:00] <Keybuk> no
[06:00] <Keybuk> the old hotplug pci.agent just skipped them
[06:00] <Keybuk> hmm
[06:00] <Keybuk> udevplug doesn't do that, of course
[06:01] <Keybuk> I wonder whether there's some modprobe.d trick we can use to blacklist an entire class
[06:03] <pitti> Keybuk: yay, a symlink works nicely, great; thanks for your help
[06:04] <Keybuk> pitti: symlink?
[06:05] <pitti> Keybuk: /dev/bus/usb/003/008 -> /dev/usbdev3.8, just for testing
[06:05] <Keybuk> ahh
[06:05] <pitti> Keybuk: that's how your udev will create the devs?
[06:05] <Keybuk> it'll rename them
[06:05] <Keybuk> there won't be a /dev/usbdev3.8
[06:06] <Keybuk> (ie. it uses NAME= not SYMLINK+=)
[06:06] <pitti> Keybuk: I mean /dev/bus/usb/xxx/yyy
[06:06] <Keybuk> oh
[06:06] <Keybuk> right
[06:06] <Keybuk> yes
[06:06] <pitti> ok, cool
[06:06] <pitti> then everything is settled
[06:06] <Keybuk> is that what gphoto actually looks for?  it's not looking for /dev/bus/usb/3/8 ?
[06:06] <pitti> libsane uses libgphoto-port0, which uses libusb, which is prepared for your udev
[06:07] <pitti> Keybuk: I have to check the code if /3/8 is also supported
[06:07] <pitti> but since /proc/bus/usb always had three digits, that's what libusb currently looks for
[06:07] <Keybuk> cause I think that's how Debian named them (which I thought was a bug, so I prematurely fixed it just in case)
[06:10] <Keybuk> oooooh
[06:10] <Keybuk> my system has booted
[06:10] <pitti> Keybuk: 'k, /dev/bus/usb/3/9 works as well
[06:10] <Keybuk> pitti: ah, so it looks for both?
[06:10] <pitti> yes
[06:10] <Keybuk> which does it "prefer", looking at the code?
[06:10] <pitti> Keybuk: whatever comes first in asciibetical order
[06:11] <pitti> i. e. 00x, I suppose
[06:11] <Keybuk> oh right
[06:11] <pitti> oh, wait, that was a lie
[06:11] <pitti> it doesn't sort
[06:11] <pitti> so, whatever readdir() delivers first
[06:11] <pitti> not that it would matter so much
[06:12] <Keybuk> I mean which of /dev/bus/xxx/yyy, /dev/bus/x/y, /proc/bus/xxx/yyy does it look for first?
[06:12] <pitti> Keybuk: /dev is prefered over /proc, which is sane
[06:12] <pitti> Keybuk: the first two are indetermined
[06:12] <Keybuk> ok
[06:12] <pitti> Keybuk: it just walks the directory with readdir()
[06:12] <pitti> but that's fine AFAICS
[06:13] <Keybuk> oh, so it doesn't actually build the path?
[06:13] <pitti> the important part is /dev > /proc
[06:13] <Keybuk> right
[06:13] <Keybuk> so I now have 5 bugs
[06:14] <Keybuk> 1) ide-generic isn't loaded, so needs to be somehow
[06:14] <Keybuk> 2) /lib/udev/ide_media gets passed the wrong thing
[06:14] <Keybuk> 3) a typo in a rules file
[06:14] <Keybuk> 4) framebuffers need blacklisting
[06:14] <Keybuk> and
[06:14] <Keybuk> 5) kernel still panics
[06:19] <Keybuk> interestingly it did #5 quite a way down the boot sequence, when hal started
[06:19] <Keybuk> so maybe iz sysfs bug
[06:26] <Keybuk> jbailey: ping?
[06:26] <jbailey> Keybuk: pong
[06:26] <Keybuk> we utterly only support built-in IDE controllers or PCI IDE controllers, right?
[06:27] <Keybuk> or does ide-generic activate anything that the PCI walk didn't?
[06:27] <Keybuk> ie. should I put "modprobe ide-generic" in a udev rule if we find a PCI IDE controller, or does it need to be out of the main sequence?
[06:31] <Keybuk> hmm, deathly silence
[06:34] <jbailey> ide-generic should activate pretty much everything else that listens at the right addresses.
[06:34] <Keybuk> ok
[06:34] <jbailey> We added it in to support random embedded things and other bits that don't have the right chips.
[06:35] <Keybuk> the trouble is that a "modprobe ide-generic" won't wait
[06:35] <Keybuk> (for /dev/hda and stuff to appear)
[06:41] <Keybuk> right
[06:41] <Keybuk> modprobe -q ide-generic
[06:41] <Keybuk> udevstart -W
[06:41] <Keybuk> :)
[06:41] <Keybuk> uh s/udevstart/udevplug/
[06:44] <jbailey> LOL
[06:44] <Keybuk> hmm, so I noticed one bug with leaving udevd running until the real filesystem
[06:44] <Keybuk> we move /dev out of the way :)
[07:17] <jbailey> The idea was to cd /dev first.
[07:17] <jbailey> Should solve that, no?
[07:36] <Keybuk> no, because it would still try and mknod /dev/foo
[07:50] <Keybuk> is ok though
[07:50] <Keybuk> if we kill it just before we exec init, and start it straight after, that's pretty short
[07:50] <Keybuk> we don't need it for exec init ... that's way after mountroot
[09:23] <Mithrandir> hiya
[09:26] <Keybuk> heyhey
[09:26] <Mithrandir> jbailey: you pung?
[09:26] <jbailey> Mithrandir: Scott wanted to know about i2o
[09:26] <jbailey> Mithrandir: Since you've actually touched one, I was hoping you could answer better than I.
[09:26] <Keybuk> no, I just wanted to know how dead I'd be if I didn't broke it on boot ;)
[09:26] <Mithrandir> sure, what's the question?
[09:26] <Keybuk> uh, PROBE it on boot
[09:26] <Keybuk> hello, freud
[09:27] <Mithrandir> Keybuk: well, the system would be completely unbootable.
[09:27] <Keybuk> that's pretty much what I wanted to know
[09:27] <Keybuk> i2o controllers are PCI storage controllers?
[09:27] <jbailey> Keybuk: I don't know what Norweigians do when they're angry, but that's what you'd have to deal with.
[09:27] <Mithrandir> unless one, for some insane reason has / on something non-i2o, that is.
[09:27] <jbailey> Tax you, or something.
[09:27] <Keybuk> jbailey: Tollef bites
[09:27] <Mithrandir> I also slap people with x40s
[09:28] <Keybuk> Mithrandir: like IDE or SCSI?
[09:28] <Keybuk> ... with their X40
[09:28] <Mithrandir> yes, but why would you do that if you have an I2O controller?
[09:28] <Keybuk> I don't know what an i2o controller is
[09:28] <Keybuk> I've never seen one before
[09:28] <jbailey> Mithrandir: That's the part you can fill in that I can't. =)
[09:28] <Keybuk> SATA I think
[09:28] <jbailey> Keybuk: sata, probably. =)
[09:28] <Mithrandir> it's a disk controller, most often SCSI on the disk interface, but can be anything.
[09:28] <jbailey> Mithrandir: Aren't there i2o nics too?
[09:29] <Mithrandir> i2o is a standardised interface, so you only have to have one driver for all kinds of hardware
[09:29] <Mithrandir> jbailey: possibly.
[09:29] <Keybuk> ah, yes
[09:29] <Keybuk> another standardised interface
[09:29] <Keybuk> the nice thing about those is there are so many of them
[09:29] <Keybuk> you just need one driver for each bloody standardised interface
[09:29] <Mithrandir> yes :-)
[09:29] <Keybuk> ok
[09:30] <Mithrandir> it's like if you had a single SCSI card adapter which worked for all scsi cards, though.
[09:30] <Keybuk> I'll leave -Bi2o in then
[09:30] <Keybuk> not that should actually have anything on it at that point
[09:30] <Keybuk> that probe is for stuff that got loaded *before* we probed the PCI bus for storage controllers
[09:30] <Keybuk> usually "elmo woz ere" type things
[09:30] <jbailey> Mithrandir: (and then couldn't find any scsi cards)
[09:31] <Mithrandir> s/adapter/driver/, though
[09:31] <Mithrandir> Keybuk: also, devices show up in /dev/i2o/hdX and not as /dev/hdX.
[09:33] <Keybuk> do they?
[09:33] <Keybuk> O:-)
[09:33] <Keybuk> perhaps you should rephrase that
[09:33] <Keybuk> maybe "could you make the devices show up in /dev/i2o" ... :)
[09:34] <Mithrandir> they should show up as /dev/i2o/hdX, not /dev/hdX. :-P
[09:34] <Keybuk> should they?
[09:34] <Mithrandir> that's what all the docs say, that's what the kernel default is and so on, so yes, I absolutely think so.
[09:34] <Keybuk> there isn't a kernel default
[09:34] <Keybuk> hmm
[09:34] <Mithrandir> MAKEDEV default, then
[09:34] <Mithrandir> unless you have a good reason for them to show up somewhere else.
[09:35] <Keybuk> there isn't a rule for that in current udev.rules ... so how does that work?
[09:35] <Keybuk> *shrug*
[09:35] <Keybuk> I guess it just does
[09:35] <Keybuk> kernel probably does something sick like DEVNAME=i2o/hdX
[09:36] <Mithrandir> on my i2o box (which runs hoary), I have both /dev/i2o_hda and /dev/i2o/hda
[09:36] <Keybuk> kooky
[09:36] <Mithrandir> (as well as i2o_hda1, i2o/hda1, etc)
[09:37] <Mithrandir> yeah, I think just i2o/hdX is good
[09:37] <Keybuk> could you do a udevinfo -q all -n /dev/i2o_hda
[09:37] <Keybuk> and udevinfo -q all -n /dev/i2o/hda
[09:37] <Mithrandir> : tfheen@my ~ > udevinfo -q all -n /dev/i2o_hda
[09:37] <Mithrandir> device not found in database
[09:37] <Mithrandir> : tfheen@my ~ > udevinfo -q all -n /dev/i2o/hda
[09:37] <Mithrandir> P: /block/i2o!hda
[09:37] <Mithrandir> N: i2o/hda
[09:37] <Mithrandir> S:
[09:37] <Mithrandir> : tfheen@my ~ >
[09:37] <Mithrandir> blank line after the S:
[09:38] <Keybuk> udevinfo -a -p '/block/i2o!hda'
[09:40] <Mithrandir> loads
[09:40] <Mithrandir> http://pastebin.com/437435
[09:43] <Keybuk> interesting
[09:46] <Keybuk> well, I guess it works
[09:46] <Keybuk> unlike my IDE controller *sigh*
[09:46] <Mithrandir> I'm going to get that particular machine available for testing in a few days, so I can do any kinds of testing you want.
[09:46] <Mithrandir> it's probably going back into production in not too long, though, as it's a dual 250 and we like to keep those busy.
[09:47] <Keybuk> *nods*
[09:57] <Mithrandir> does that mean "please tell me when you've installed dapper on it and what breaks"?
[09:57] <Keybuk> yup
[09:57] <Keybuk> pretty much
[09:58] <Mithrandir> it'll be easy for me to give out access to the box when it's reinstalled, if you're interested.
[09:58] <Keybuk> sounds good
[09:59] <Keybuk> theoretically it should all be fine though
[09:59] <Keybuk> I can't see any special handling for i2o in Debian or SuSE's rules
[09:59] <Mithrandir> yeah, and in theory theory and practice are equal.
[09:59] <Keybuk> which probably means it was written a not-too-insane man
[09:59] <Keybuk> and the kernel actually knows how to drive it
[09:59] <Mithrandir> the original driver was written by a Mr. Cox.
[09:59] <Mithrandir> you might have heard of him.
[10:00] <Keybuk> indeed
[10:00] <Mithrandir> he's probably insane, but in the good sense of the word.
[10:00] <Keybuk> :o)