[01:35] <kylem> BenC, what's the ubuntu firmware policy? (specifically the qlogic firmware for qla2xxx)
[01:35] <mjg59> What aspect of the policy?
[01:35] <BenC> if they will let us redistribute it, we stick it into the kernel
[01:36] <BenC> under debian/firmware/
[01:36] <kylem> well, you can optionally build the firmware in, but the recommended thing to do is load it from userspace.
[01:36] <kylem> (recommended by the driver authors)
[01:36] <BenC> if redistribution is "everyone does it, and the vendor says it doesn't care, but we have no real license", then it goes in lrm
[01:36] <kylem> drivers/scsi/qla2xxx/Kconfig, there was a bug report to turn on QLA_FC in edgy kernel, zul submitted a patch, but neglected to frob the other options...
[01:37] <BenC> e.g. acx is in lrm, ipw3945 is in main kernel
[01:37] <mjg59> Oh, right
[01:37] <kylem> this is the tg3 style firmware, a static char[]  array
[01:37] <mjg59> kylem: If it's recommended to load from userspace, then do that
[01:37] <BenC> yeah, definitely
[01:37] <mjg59> kylem: But it'll want an initramfs-tools tweak to make sure it's copied into the initramfs
[01:37] <kylem> yeah, except then you can't easily boot of it...
[01:38] <mjg59> We handle firmware loading from initramfs
[01:38] <BenC> infinity: ping
[01:38] <infinity> pong
[01:38] <BenC> infinity: I need a initramfs-tools update soonish so I can have pata_* drivers working
[01:38] <BenC> can I do a quick upload just for this, or do you have larger plans?
[01:39] <infinity> BenC: Go hard.  I have notihng interesting pending.
[01:39] <BenC> ok
[01:39] <BenC> is this one of those uploads that falls into the category of "cjwatson will kill me if I don't follow some policy"?
[01:40] <infinity> pata_* == libata PATA drivers?
[01:40] <mjg59> initramfs-tools is fine
[01:40] <mjg59> Just don't screw it up
[01:40] <BenC> infinity: Yeah
[01:40] <mjg59> Oh, uh.
[01:40] <infinity> Yeah, leave my system unbootable, and I'll curse your name, otherwise it's all good.
[01:40] <mjg59> Is there any HPA handling code in libata yet?
[01:40] <mjg59> And if not, do HPAs default to being enabled or disabled?
[01:40] <BenC> mjg59: good question
[01:41] <mjg59> Because that'll, like, kill people who've wiped their Thinkpad rescue partition but didn't disable the HPA in the BIOS
[01:41] <BenC> I only enabled the pata drivers that were not exp.
[01:41] <mjg59> This is ata_piix
[01:41] <BenC> let me check that one
[01:42] <mjg59> Given that the "fix" is a simple BIOS tweak, it's not a real issue
[01:42] <mjg59> But it needs to be flagged as a blocker until we fix it
[01:42] <mjg59> It's like 3 lines of code
[01:42] <BenC> ok
[03:07] <BenC> infinity: Oooh, copy_modules_dir made my job easy
[03:08] <BenC> ata) copy_modules_dir kernel/drivers/ata;;
[03:09] <BenC> I wonder if it's a good idea to do that for scsi too
[03:09] <BenC> and ide
[03:10] <infinity> If that now works for everything we want, then hells yes.
[03:13] <BenC> I'll test it on all my machines before uploading
[03:13] <BenC> I added an "ata" for the auto load list, since pata/sata are now all in drivers/ata
[03:13] <BenC> and I know for sure that ide and scsi module lists are outdated anyway
[03:16] <infinity> They get old fast, yeah.
[03:31] <BenC> my concern now is initrd size
[03:32] <infinity> Oh, are we including all the old ide drivers AND the new pata ones?
[03:32] <infinity> I guess that could get somewhat bigger.
[03:32] <infinity> Though we're building 'em bloated anyway... *shrug*
[03:32] <BenC> no, I disabled the ide drivers that were replaced by the IDE ones
[03:33] <BenC> about 500k size increase with the copy_modules_dir {ata,scsi,ide} as opposed to the old method
[03:33] <infinity> Oh, kernel/drivers/ata/ is tiny, don't worry about it.
[03:33] <BenC> err, replaced by the pata ones
[03:33] <infinity> Well, "tiny" compared to my 6.3MB initrd.
[03:33] <BenC> I think the additional scsi drivers caused the size increase
[03:33] <BenC> I know there's more than what's in that list
[03:33] <infinity> Yeah, you may have added some.
[03:34] <infinity> *shrug*
[03:35] <infinity> scsi is definitely the big one.
[03:35] <infinity> Not much we can do about that.
[03:36] <infinity> Although, do we really still need two aic7xxx drivers?
[03:37] <BenC> I don't think they overlap
[03:37] <kylem> BenC, any idea why qla2xxx/qla fiber channel is off in edgy/feisty kernels? (or was it just an oversight when it changed from being CONFIG_SCSI_QLA2XXX)
[03:37] <infinity> We never included _old in our initrds, and I've not had a complaint.
[03:38] <infinity> That may be telling.
[03:39] <BenC> infinity: _old doesn't even have a dev table
[03:39] <BenC> maybe I can just disable it
[03:39] <BenC> kylem: perhaps, let me check
[03:41] <infinity> BenC: It's not referenced/loaded from the new aic7xxx driver on the fly when old hardware is encountered, or something equally GNAH?!
[03:41] <infinity> BenC: With no dev table, I'm curious as to why it's there at all. :)
[03:42] <BenC> infinity: My thoughts exactly, unless it's one of those weird platform drivers :)
[03:42] <BenC> probably can be disabled
[03:43] <BenC> kylem: My guess is it's an oversight
[03:43] <infinity> Could be one of those "this driver is the only one that works on Alpha, cause the other one needs some cleaning up" cases, or something, but as (like I said) we've not once had a complaint about it not being in our initrds, I somehow doubt any of our users care.
[03:43] <kylem> BenC, ok, i've turned it back on in edgy-updates.
[03:44] <kylem> on all but parisc, since it will likely fail there anyway.
[03:44] <BenC> I'll enable it in feisty
[03:44] <BenC> and get the firmware
[03:44] <infinity> kylem: There is no edgy/hppa.
[03:44] <kylem> infinity, that too.
[03:44] <kylem> aic7xxx_old.c gets the puke-o-rama of the day award.
[03:44] <infinity> (So no point in caring if a change will or won't biuld there)
[03:44] <BenC> I wish we had someone with canonical that knew hppa
[03:44] <BenC> oh wait
[03:45] <kylem> let me finish ATs first...
[03:46] <infinity> Would I get fired for proposing that feisty+1 be a parisc-only release, and we drop all the boring arches?
[03:46] <infinity> "Everyone else is doing these ones anyway, we want to stick out and be unique!"
[03:46] <BenC> hehe
[03:47] <infinity> We could get lamont involved and ship a C200 with every shipit CD.
[03:47] <mjg59> Oh. My. Christ.
[03:47] <BenC> might as well stick "sh" in there as well
[03:47] <mjg59> Look at aic7xxx_detect in aic7xxx_old.c
[03:47] <infinity> BenC: Harder to get our hands on stacks of Dreamcasts.
[03:47] <kylem> mjg59, it's love.
[03:47] <infinity> (Well, actually, DCs are easy to come by, it's the ethernet adapter that's rarer than kyle's sobriety)
[03:48] <lamont> infinity: heh
[03:48] <kylem> mjg59, would you rather hack that or acpi?
[03:48] <kylem> infinity, hey, i've not had a drink since boatnight. :)
[03:48] <infinity> kylem: Been ill? ;)
[03:48] <kylem> and even then, i was sick enough without alcohol
[03:48] <mjg59> ACPI
[03:48] <BenC> mjg59: holy shit, it's like half the code in there
[03:48] <mjg59> pci_find_device!!!
[03:49] <mjg59> Yeah. Uhm.
[03:49] <mjg59> I think we don't support that driver.
[03:49] <infinity> Oh, is aic7xxx_old one of those really, really old drivers that does all the PCI legwork itself still?
[03:49] <kylem> infinity, yes.
[03:49] <kylem> the driver appears to be older than i am.
[03:49] <mjg59> !
[03:49] <infinity> I thought those were purged from the tree long ago, for fear of setting a bad example for future generations.
[03:49] <mjg59>         if ( i == 0 ) /* We found one, but it's the 7810 RAID cont. */
[03:49] <ajmitch> maybe it scared too many people away from cleaning up
[03:50] <mjg59> Is entirely dependent upon the 7810 being the first entry in the array
[03:50] <mjg59> This isn't mentioned in the array itself
[03:50] <kylem> ajmitch, better to dust off and nuke the driver from orbit... it's the only way to be sure.
[03:50] <mjg59> It supports VLB
[03:50] <mjg59> Which aic7xxx might not
[03:50] <mjg59> But, erm.
[03:50] <infinity> mjg59: And as scary as all that is, I recall the old aic7xxx driver (before it was rewritten) being a stellarly stable and useful driver, a paragon of hardware vendor involvement for the greater good.
[03:51] <kylem> fuck VLB.
[03:51] <infinity> I think our standards must have been lower back then.  Where "back then" was, what, the 60s?
[03:51] <mjg59> The 1860s?
[03:52] <zul> hey
[03:52] <zul> just popping by and will be off soon
[03:53] <ajmitch> evening zul 
[03:56] <BenC> ok, let's reboot and see how this new initramfs did
[04:04] <BenC> all is well, initramfs-tools uploaded
[05:00] <BenC> Is "" a legitimate SSID?
[05:43] <KnowledgEngi> hello
[05:43] <KnowledgEngi> sudo apt-get install linux-tree
[05:43] <KnowledgEngi> why apt do not find linux-tree
[05:43] <KnowledgEngi> ??
[05:43] <KnowledgEngi> http://wiki.ubuntu-it.org/CompilazioneKernel?highlight=%28kernel%29
[05:44] <KnowledgEngi> i'm using this how-to
[05:45] <infinity> s/linux-tree/linux-source/
[05:46] <infinity> Though that howto is pretty sketchy.  Doing all that as root is pointless.
[05:46] <BenC> anything not listed directly in the URL above is pretty much unsupported and probably broken
[05:46] <BenC> s/above/in the topic/
[05:49] <KnowledgEngi> i whant just to change the cpu timer frequency 
[05:49] <KnowledgEngi> i need only this modific
[05:49] <KnowledgEngi> the rest under ubuntu work very good
[05:50] <BenC> the above URL has a link to a howto for rebuilding the ubuntu kernel properly with small config changes like what you want
[05:52] <KnowledgEngi> This is a bad bear. Use it, but there are still a few missing modules.
[05:52] <KnowledgEngi> for this argoment i do not whant use a different kernel version
[05:57] <KnowledgEngi> https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28CategoryKernel%29
[05:57] <KnowledgEngi> this page???
[05:57] <infinity> Why can't we influence the timer on the command line anyway?
[05:58] <KnowledgEngi> i do not know
[05:58] <KnowledgEngi> i know that yesterday i has solved the problem rebuilding the kernel
[05:58] <BenC> infinity: Hardcoded into a lot of macros
[05:59] <KnowledgEngi> i was using a software for musician
[05:59] <KnowledgEngi> that need a low-latency kernel
[05:59] <infinity> BenC: Well, yes, I was fairly sure that was the answer, it was more of a "can't this be fixed?" thing.
[05:59] <kylem> way more efficient for it to be an immediate than to constantly reload from memory... 
[05:59] <infinity> kylem: And yes, that's the "why".
[05:59] <fabbione> morning
[05:59] <BenC> hey fabbione
[05:59] <fabbione> KnowledgEngi: yes i am italian but please don't /msg me just for that :)
[06:00] <fabbione> BenC: just saw your initramfs upload. thanks
[06:00] <KnowledgEngi> i'm italian too
[06:00] <fabbione> will test once it's in the local mirror
[06:00] <KnowledgEngi> but my english is very bad
[06:00] <BenC> fabbione: no problem
[06:00] <KnowledgEngi> for me is hard to explain the situation in english
[06:00] <kylem> infinity, extremely.
[06:00] <KnowledgEngi> can i query you fabbione 
[06:00] <KnowledgEngi> ?
[06:00] <fabbione> KnowledgEngi: what do you need?
[06:01] <BenC> he needs to rebuild the kernel with HZ=1000
[06:01] <infinity> kylem: The only reason I'm pondering it at all is due to the frequency of people needing to change that.. Uhh.. Frequency.
[06:01] <KnowledgEngi> exatly
[06:01] <BenC> and I pointed him to the URL in the topic, which led to the kernelBuild wiki page, whihc is where he needs to be
[06:01] <fabbione> and why do you need to keep that in a query?
[06:01] <KnowledgEngi> i whant that kernel and modules ar the same that i have now
[06:01] <kylem> infinity, HZ=1000 isn't really enough to give them low latency.
[06:01] <KnowledgEngi> but the only dfifference that i need is the HZ
[06:01] <KnowledgEngi> change it from 250 to 1000
[06:02] <infinity> kylem: No, but it does help measurably.
[06:02] <BenC> KnowledgEngi: The KernelBuild wiki page you found is what you want
[06:02] <KnowledgEngi> i do not like use make oldconfig
[06:02] <kylem> why don't the UbuntuStudio or whatever people ship one with the lowlatency patchkit anyway?
[06:02] <KnowledgEngi> becouse he show me much question that i cannot answare
[06:03] <infinity> kylem: There was much talk of it during the dapper cycle.  Not sure where it went.
[06:03] <KnowledgEngi> becouse ubuntustudio have tha same problem
[06:03] <BenC> KnowledgEngi: There will be no questions if you follow the instructions
[06:03] <infinity> We even have userspace realtime stuff in glibc and pam, specifically for said group.
[06:04] <KnowledgEngi> sudo apt-get install linux-kernel-devel fakeroot kernel-wedge kernel-package
[06:04] <KnowledgEngi> from here ???
[06:05] <fabbione> KnowledgEngi: from the first line of the page
[06:06] <KnowledgEngi> the firsth 2 part tall nothing about procedure
[06:07] <KnowledgEngi> Disclaimer
[06:07] <KnowledgEngi> Reasons for compiling a custom kernel
[06:07] <KnowledgEngi> Reasons for not compiling a custom kernel
[06:07] <KnowledgEngi> this 3 parts tall nothing
[06:16] <KnowledgEngi> sudo apt-get install linux-source
[06:16] <KnowledgEngi> this are the same sources of ubuntu edgy kernel ??
[06:28] <KnowledgEngi> sudo apt-get install linux-source
[06:28] <KnowledgEngi> sudo -xvjf linux-source-2.6.17.tar.bz2
[06:28] <KnowledgEngi> cp /boot/config-2.6.17-10-generic linux-source-2.6.17/.config
[06:28] <KnowledgEngi> this is correct??
[06:29] <KnowledgEngi> becouse this page speack about arch/....
[06:52] <KnowledgEngi> http://rafb.net/paste/results/MTGUMG60.html
[06:52] <KnowledgEngi> is correct ??
[06:53] <KnowledgEngi> this is all command that i writed in the terminal for build a kernel adding a option in the configuration
[06:53] <KnowledgEngi> i'm not totally sure that is correct
[08:03] <fabbione> BenC: i am looking at that kmap_atomic OOPS
[08:03] <fabbione> it's intersting piece of code
[08:04] <fabbione>  * However when holding an atomic kmap is is not legal to sleep, so atomic
[08:04] <fabbione>  * kmaps are appropriate for short, tight code paths only.
[08:04] <fabbione> and libata is a client for it
[08:04] <fabbione> pata_via does nothing there
[08:04] <fabbione> so i wonder if pata_via does actually takes too long and make things go south
[08:04] <fabbione> the BUG(); there is very specific
[08:12] <dade`> where is the default config file in the kernel development git tree ?
[08:15] <fabbione> debian/config/$arch/config{,$flavour}
[08:16] <dade`> thx
[08:37] <KnowledgEngi> include/asm/byteorder.h:5:28: error: linux/compiler.h: No such file or directory
[08:37] <KnowledgEngi> is normal ???
[08:38] <KnowledgEngi> http://rafb.net/paste/results/c4LYkw68.html
[08:47] <dade`> fabbione: I don't understand the config.generci has only few values set.
[08:47] <dade`> generic
[08:48] <fabbione> dade`: cat config config.generic > .config
[08:48] <fabbione> KnowledgEngi: yes normal
[08:48] <dade`> fine
[08:49] <KnowledgEngi> sudo dpkg -i linux-image-2.6.17-2-ef427c-k7_2.6.17-2.2_i386.deb
[08:49] <KnowledgEngi> sudo dpkg -i linux-headers--2.6.17-2-ef427c-k7_2.6.17-2.2_i386.deb
[08:49] <KnowledgEngi> in what path i must run this commands?
[08:50] <KnowledgEngi> root@ubuntu:/usr/src/linux-source-2.6.17# 
[08:50] <KnowledgEngi> here?
[08:51] <KnowledgEngi> root@ubuntu:/usr/src# ls *ubuntu*
[08:51] <KnowledgEngi> linux-doc-2.6.17.13-ubuntu1_2.6.17-10.33_all.deb
[08:51] <KnowledgEngi> linux-headers-2.6.17.13-ubuntu1_2.6.17-10.33_i386.deb
[08:51] <KnowledgEngi> linux-image-2.6.17.13-ubuntu1_2.6.17-10.33_i386.deb
[08:51] <KnowledgEngi> linux-manual-2.6.17.13-ubuntu1_2.6.17-10.33_all.deb
[08:51] <KnowledgEngi> linux-source-2.6.17.13-ubuntu1_2.6.17-10.33_all.deb
[08:51] <KnowledgEngi> linux-source-2.6.17.13-ubuntu1_2.6.17-10.33_i386.changes
[08:51] <KnowledgEngi> mmmm
[08:52] <KnowledgEngi> aa dpkg -i is for install
[08:52] <KnowledgEngi> :P
[08:53] <dade`> fabbione: is there a doc where all those lame questions are answered ? :)
[08:53] <KnowledgEngi> fabbione, did you see the procedure in the file that i pasted?
[08:53] <fabbione> dade`: usually if you don't know the answers, it means you shouldn't be compiling your own kernel
[08:54] <fabbione> KnowledgEngi: no. i don't have time to babysit custom kernel builds. sorry
[08:54] <KnowledgEngi> is just some line
[08:54] <dade`> I thought it was that way, but was just guessing..
[08:54] <KnowledgEngi> http://rafb.net/paste/results/c4LYkw68.html
[08:55] <KnowledgEngi> hello JanC 
[08:55] <KnowledgEngi> can you tall me if this small procedure is ok?
[08:55] <KnowledgEngi> http://rafb.net/paste/results/c4LYkw68.html
[09:10] <KnowledgEngi> hello :(
[09:11] <KnowledgEngi> kernel panic: not syncin, unable to mount root on fs .....
[09:11] <KnowledgEngi> http://rafb.net/paste/results/NS8Tpk66.html
[09:11] <KnowledgEngi> i think that it's a problem initrd related
[09:48] <KnowledgEngi> mkinitramfs -o /boot/initrd.img-2.6.17-13-ubuntu1
[09:48] <KnowledgEngi> i adjusted the menu.lst
[09:49] <KnowledgEngi> but when i reboot i see the ubuntu presentation 
[09:49] <KnowledgEngi> and STOP
[09:51] <KnowledgEngi> http://rafb.net/paste/results/5R0GpE33.html
[09:53] <KnowledgEngi> when the system print "ubuntu" in the monitor it do not continue
[10:15] <KnowledgEngi> the kernel config file is needed only for build the kernel ???
[10:15] <KnowledgEngi> or is needed for working good too?
[10:24] <KnowledgEngi> idea, i remove splash from menu.lst
[10:24] <KnowledgEngi> and i look the errors
[10:24] <KnowledgEngi> by
[10:43] <KnowledgEngi> hello
[10:43] <KnowledgEngi> now i has see the error deleting splash from menu.lst
[10:43] <KnowledgEngi> http://rafb.net/paste/results/BrnMiE89.html
[10:43] <KnowledgEngi> in the page there is the errors 
[10:54] <KnowledgEngi> BenC, can you help me please :(
[10:54] <KnowledgEngi> i used the how-to in the topic
[10:55] <KnowledgEngi> http://rafb.net/paste/results/FeSfGz78.html
[11:06] <KnowledgEngi> make-kpkg buildpackage
[11:06] <KnowledgEngi> the error was here
[11:06] <KnowledgEngi> make-kpkg --append-to-version -1000hz --revision=1 kernel_image --initrd
[11:06] <KnowledgEngi> someone suggest me this command
[12:20] <fabbione> BenC: are we really sure we want to go for libata?!?!?
[12:20] <fabbione> http://www.spinics.net/lists/linux-ide/msg04744.html
[12:20] <fabbione> drivers/ide IS STILL THE PATA DRIVER SET THAT USERS AND DISTROS SHOULD CHOOSE. <-
[01:00] <KnowledgEngi> hello
[01:00] <KnowledgEngi> the how-to was wrong
[01:01] <KnowledgEngi> http://rafb.net/paste/results/t7YeAc68.html
[01:01] <KnowledgEngi> now the kernel are not giving me problem
[01:01] <KnowledgEngi> *are=is
[01:03] <pmjdebruijn> KnowledgEngi, huh? you're not exactly clear...
[01:05] <KnowledgEngi> https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28CategoryKernel%29
[01:05] <KnowledgEngi> this how-to tall the i must do make-kpkg buildpackage
[01:05] <pmjdebruijn> KnowledgEngi, yes, and your point is?
[01:06] <KnowledgEngi> make-kpkg --append-to-version -1000hz --revision=1 kernel_image --initrd
[01:06] <KnowledgEngi> this is better
[01:43] <Keybuk> BenC: so, I think ide-generic is broken ...
[01:49] <infinity> This is news?
[02:00] <Keybuk> in the sense that it actually doesn't work at all
[02:00] <Keybuk> if you load it before the PCI driver, it claims the device (when it shouldn't!) but doesn't make block devices
[02:08] <gnomefreak> is the -6 kernel a full kernel now?
[02:08] <mjg59> Why should it not claim the device?
[02:09] <mjg59> It'll grab all IDE interfaces that are running in legacy mode. That's what it's for.
[03:06] <Keybuk> but then it'll grab interfaces for which there's a better driver that just hasn't been loaded yet?
[03:07] <mjg59> How is it to know?
[03:08] <Keybuk> blacklist of pci ids?
[03:08] <Keybuk> (it's also broken in the fact even when it loads, it doesn't expose any block devices -- but that's another story)
[03:08] <mjg59> How would you generate the blacklist?
[03:08] <Keybuk> automatically
[03:08] <mjg59> From what?
[03:08] <Keybuk> list of pci ids for which we do have drivers
[03:09] <mjg59> And if the user builds a driver separately?
[03:09] <Keybuk> *shrug*
[03:09] <Keybuk> the fact is at the moment we can't load ide-generic
[03:09] <Keybuk> because it breaks systems for which there's a better driver
[03:09] <mjg59> Because even if it's loaded after the other drivers, it may bind first?
[03:10] <Keybuk> because we don't have anywhere to load it to guarantee that it's loaded after the other drivers
[03:10] <Keybuk> and yes, there's a binding issue with libata
[03:10] <mjg59> The driver is functioning precisely as designed
[03:10] <Keybuk> libata isn't as quick to bind as the old ide drivers
[03:10] <mjg59> If this is causing problems, then we should figure out what to do with upstream
[03:11] <Keybuk> istr that ide-generic is deprecated in favour of something in libata
[03:11] <mjg59> There's probably an identical module in libata which will have identical issues
[03:11] <Keybuk> there's fun games like two ide controllers in the machine, the one with the lower pci id needs ide-generic, the higher one has its own drier
[03:12] <Keybuk> which we can't deal with at the moment, because ide-generic steals both
[03:12] <mjg59> It doesn't "steal". It does what it's asked to do.
[03:12] <Keybuk> I still think that driver binding is best off left to user space <g>
[03:12] <Keybuk> loading modules makes drivers available, but it's up to userspace to bind to devices, etc.
[03:12] <infinity> Haven't we had this conversation before?
[03:12] <infinity> Like, before the dapper release?
[03:12] <mjg59> I'm not going to argue against that
[03:12] <mjg59> But given that ide-generic doesn't bind to PCI devices...
[03:12] <infinity> I was getting libata/ide-generic races on my laptop, and we worked around it then.
[03:13] <Keybuk> infinity: yeah, we put some hacks in place for dapper with ide-generic that we knew would break when this day occurred
[03:13] <Keybuk> surprisingly, they broke
[03:13] <infinity> Although, "ide-generic not exposing block devices" is new..
[03:13] <Keybuk> right
[03:14] <infinity> I just got my stuff swapping between /dev/sd* and /dev/hd* depending on who won the race.
[03:14] <Keybuk> I wouldn't have caught (or immediately cared) the new winner of the race unless there was this other bug :)
[03:15] <mjg59> You'd probably have cared when you noticed you had no DMA
[03:15] <Keybuk> probably, yes
[03:16] <mjg59> pata_legacy is the replacement
[03:16] <Keybuk> right, and that specifically ignores PCI devices, iirc?
[03:17] <mjg59> No
[03:17] <mjg59> It doesn't scan ide0 or ide1
[03:17] <Keybuk> ?
[03:17] <mjg59> In legacy mode, IDE busses are found at specific ports
[03:18] <mjg59> pata_legacy ignores the first two sets of these
[03:18] <Keybuk> right
[03:18] <Keybuk> why does it do that?
[03:18] <Keybuk> surely it needs to look at them for ISA ide devices?
[03:18] <mjg59>  *      Right now we do not scan the ide0 and ide1 address but should do so
[03:18] <mjg59>  *      for non PCI systems or systems with no PCI IDE legacy mode devices.
[03:18] <Keybuk> ahh
[03:19] <infinity> Is there a timeframe on fixing that?
[03:19] <mjg59> Well, it's trivial to make it behave like ide-generic again
[03:19] <Keybuk> doesn't it also explicitly iterate the PCI bus, looking for PCI devices?
[03:20] <mjg59> Oh, actually, the comment appears to be wrong
[03:20] <Keybuk> yeah
[03:20] <Keybuk> I was reading the code
[03:20] <Keybuk> the code looks like it only ignores ide0 and ide1 if there's a PCI ide controller
[03:20] <mjg59> It'll skip ide0 and ide1 iff it's found a PCI device at those addresses
[03:20] <Keybuk> 858                         if (pci_resource_start(p, r) == 0x1f0)
[03:20] <Keybuk> 859                                 primary = 1;
[03:20] <Keybuk> 860                         if (pci_resource_start(p, r) == 0x170)
[03:20] <Keybuk> 861                                 secondary = 1;
[03:21] <mjg59> And unless you pass it a magic option, it'll ignore anything after ide1
[03:21] <mjg59> So loading it would be a noop on most systems
[03:21] <Keybuk> of course, Ben doesn't appear to have compiled this ;)
[03:21] <mjg59> Well, given that it'd be a noop on any PCI systems...
[03:22] <mjg59> Christ, you can tell this driver was written by Alan
[03:22] <Keybuk> we still want it for non-PCI systems though?
[03:22] <mjg59> Yeah
[03:22] <Keybuk> . o O { if only we could declare "feisty is for PCI only, HA HA" }
[03:22] <mjg59> I guess we might support, ooh, 3 or so of those?
[03:23] <Keybuk> I'd be surprised if anything booted on non-PCI, frankly <g>
[03:23] <Keybuk> but I've generally tried not to break things
[03:23] <mjg59> So the issue then is that we won't drive any PCI adapters unless we have a specific driver for them
[03:23] <infinity> Well, they run monolithic kernels anyway, but still...
[03:23] <Keybuk> mjg59: that's fine though, because libata has a generic ata thing for those adapters, no?
[03:24] <mjg59> No?
[03:24] <Keybuk> modinfo ata_generic
[03:24] <Keybuk> which backs off if a better driver gets loaded
[03:24] <mjg59> Oh, I'm looking in an excessively old kernel tree
[03:24] <Keybuk> (my laptop is driving with ata_generic today -- so I know it works <g>)
[03:24] <mjg59> Let me finish pulling down 2.6.19
[03:25] <Keybuk>  11  *  Driver for PCI IDE interfaces implementing the standard bus mastering
[03:25] <Keybuk>  12  *  interface functionality. This assumes the BIOS did the drive set up and
[03:25] <Keybuk>  13  *  tuning for us. By default we do not grab all IDE class devices as they
[03:25] <Keybuk>  14  *  may have other drivers or need fixups to avoid problems. Instead we keep
[03:25] <Keybuk>  15  *  a default list of stuff without documentation/driver that appears to
[03:25] <Keybuk>  16  *  work.
[03:25] <Keybuk> the first bit of that comment is a lie
[03:26] <Keybuk> alias: pci:v*d*sv*sd*bc01sc01i*
[03:26] <Keybuk> :p
[03:26] <mjg59> Oh
[03:27] <mjg59> That's just the same as pci/generic.c
[03:27] <mjg59> It doesn't help in the case of new hardware appearing
[03:27] <Keybuk> ?
[03:27] <mjg59> Well, again assuming that the comment has any relation to reality
[03:27] <mjg59> (Which, as we've already seen, may not be a good plan)
[03:28] <mjg59> It'll load for all IDE class devices, but only bind if they hit the built-in whitelist
[03:28] <Keybuk> that can't be true, because it's loaded on my laptop
[03:28] <Keybuk> which isn't in the whitelist
[03:28] <mjg59> Are you sure it's bound?
[03:28] <Keybuk> *confused*
[03:28] <Keybuk> well, I can't see any other driver
[03:28] <mjg59> Can you stick lspci somewhere?
[03:28] <mjg59> Uh, lsmod
[03:29] <Keybuk> oh, wait, alim15x3 ... laptop is still using the old non-libata driver
[03:30] <Keybuk> so right, we have the general problem of new hardware that we don't have a driver for, or at least the pci id for, appearing and failing to boot because there's no IDE driver and no "generic" driver to claim it?
[03:30] <mjg59> Yes
[03:31] <Keybuk> we'd need to set all_generic_ide=1 or something
[03:31] <mjg59> But then it'll bind to everything, even if there's a better driver
[03:31] <Keybuk> yeah
[03:32] <Keybuk> we could make it a kernel option, then at least we can document it :)
[03:32] <mjg59> I guess you could poke bind/unbind stuff
[03:32] <mjg59> But yeah, I'm happy with the idea of just disabling ide-generic and having initramfs pass all-generic-ide to the ata_generic module if the user supplies it on the kernel boot line
[03:33] <mjg59> Then users with excessively bling hardware can just add that boot option at install time
[03:33] <Keybuk> I wonder how often new IDE controllers come out these days
[03:33] <Keybuk> (that aren't SATA)
[03:33] <mjg59> Several in the past few months
[03:33] <mjg59> Things will probably settle down again now
[03:34] <mjg59> Intel took PATA out of ICH8
[03:34] <Keybuk> I guess I also need to kick Ben, most of the libata modules aren't compiled :p
[03:34] <mjg59> We also need all the latest pata patches from -mm and anything that Alan has posted to LKML lately
[03:34] <Keybuk> *nods*
[03:34] <mjg59> Otherwise a moderate number of them will cause corruption over suspend/resume
 http://www.spinics.net/lists/linux-ide/msg04744.html
 drivers/ide IS STILL THE PATA DRIVER SET THAT USERS AND DISTROS SHOULD CHOOSE. <-
[03:35] <fabbione> ^^
[03:35] <fabbione> this was a quote from Jeff for .19
[03:35] <mjg59> Yes. We're not shipping .19.
[03:36] <fabbione> mjg59: no matter if we land for .20 we are still with .19 for a while
[03:36] <mjg59> Someone has to test this code in the real world. It might as well be us.
[03:36] <mjg59> We can revert with approximately no effort.
[03:37] <fabbione> right, but it would be wise to coordinate with upstream before even entering a testing phase
[03:37] <fabbione> and i don't think that has been done
[03:37] <Keybuk> we've been testing libata for 6 months now
[03:38] <fabbione> Keybuk: libata doesn't seems to be the primary issue
[03:38] <Keybuk> then what is?
[03:38] <infinity> I'm all for us ironing out the wrinkles while we're still ages away from another LTS.
[03:38] <fabbione> Keybuk: the drivers using it.
[03:38] <infinity> And, hey, now that we have kyle on staff, we have a kernel rock star, so it's all good.
[03:39] <fabbione> Keybuk: see 72824 for example
[03:39] <Keybuk> some of the drivers using it are clearly better than the ide ones
[03:39] <mjg59> Most of the drivers are fine
[03:39] <mjg59> And it's actually practical to fix bugs in them, unlike drivers/ide
[03:39] <Keybuk> we shipped edgy preferring some libata pata drivers over the old ide subsystem
[03:41] <Keybuk> mjg59: interesting, I loaded ata_generic with all_generic_ide=1 and it hasn't actually picked up my card
[03:42] <Keybuk> it found the ide ports, bitches a lot about a port being "too slow", and then stays loaded with no interfaces
[03:42] <Keybuk> I did get a /dev/sg0
[03:42] <Keybuk> oh, heh
[03:42] <Keybuk> need sd_mod
[03:43] <Keybuk> hmm, that should've auto-loaded ... wonder why it didn't
[03:45] <Keybuk> ahh
[03:45] <Keybuk> udev rules bug :)
[03:54] <Keybuk> ok, that all works
[03:54] <Keybuk> my laptop boots happily with ata_generic if forced
[03:54] <Keybuk> and the UUID stuff transitioned it nicely too
[03:54] <kylem> sweet.
[03:55] <Keybuk> happily nobody with a SCSI or SATA card tried upgrading udev this afternoon
[04:00] <mjg59> Keybuk: Excellent
[04:01] <mjg59> Keybuk: So we just need initramfs-tools to pass that through if the user provides it
[04:01] <Keybuk> yeah
[04:01] <Keybuk> mdz has a general "I want some way of forcing a driver bind" desire which came out of some s3kr3t meeting at UDS
[04:01] <Keybuk> so I may do it with that
[04:02] <Keybuk> unless I carry on stamping my foot about how irritatingly impossible it is to do this <g>
[04:06] <Keybuk> I wonder how much traction upstream a "binding in user space" patch would get
[04:10] <infinity> Keybuk: me, kyle, and ben discussed that very thing in SFO.
[04:10] <infinity> (userspace binding, that is)
[04:14] <Keybuk> it makes some amount of sense
[04:14] <Keybuk> if userspace got to decide which module got which device, we'd have a lot less problems
[04:14] <infinity> Indeed.
[04:14] <infinity> We discussed some rationale, and some hand-wavey "how could we do this", but didn't actually talk implementation.
[04:15] <Keybuk> you'd need to sort out the distinction between modules and drivers
[04:15] <infinity> But the general idea seems sound.
[04:15] <mjg59> It is, sadly, not workable in certain cases
[04:15] <Keybuk> so that device binding is either done at the module level (in which case drivers go away), or drivers become a first class object with uevents, etc.
[04:15] <mjg59> For instance, the PCI dev table can have a pointer to a structure in the data field
[04:15] <Keybuk> and then have external tables that udev can look up whenever a device is added, or driver/module added, and mate the two
[04:16] <Keybuk> right
[04:16] <Keybuk> the special casing
[04:16] <mjg59> Yes
[04:16] <Keybuk> it doesn't prevent anything
[04:16] <Keybuk> it just means the special casing lists and the supported device lists become different
[04:16] <mjg59> It would need some rewriting of certain modules
[04:16] <Keybuk> sure
[04:17] <Keybuk> in fact, all modules would need the device table removed and a .inf file written
[04:17] <BenC> Keybuk: can you summarize ide-generic so I don't have to read all this scrollback :)
[04:18] <Keybuk> BenC: ide-generic is broken, if you load it, you don't get any block devices
[04:18] <Keybuk> and it's loading too quickly because of some other changes, and stealing the PCI devices
[04:18] <Keybuk> so I've disabled loading entirely
[04:18] <Keybuk> FTW we appear to need to load pata_legacy (not yet compiled) for non-PCI interfaces, which doesn't steal
[04:19] <Keybuk> and have an option to force ata_generic to take devices it's unaware of, so people with unknown IDE interfaces can still boot
[04:19] <BenC> known, was going to work on it when I got the box that elmo sent me from UDS
[04:19] <Keybuk> tbh, if pata_legacy and ata_generic dtrt (which they appear to), I'm tempted to remove ide-generic entirely and sing a little song about it
[04:19] <BenC> pata_legacy is marked "dangerous" IIRC
[04:20] <BenC> let me check again
[04:20] <mjg59> I disagree that ide-generic is broken, but would concur that we shouldn't be trying to load it by default
[04:20] <Keybuk> mjg59: well, it's working according to its design
[04:20] <mjg59> Keybuk: How about leaving ide-generic built, and have a boot option that force-loads it?
[04:20] <Keybuk> I'd be happy with just not loading it unless someone wants it loaded
[04:20] <Keybuk> yes, I'd be happy with that
[04:20] <mjg59> It has no modalias entries
[04:21] <BenC> sounds like a plan to me
[04:21] <mjg59> ubuntu-2.6 is the 2.6.19 branch, right?
[04:21] <BenC> but ONLY if there's something in the installer to recoginize that and marshall it into the installed system
[04:21] <BenC> mjg59: Right
[04:21] <Keybuk> BenC: the installer could pick up the same option from its own boot? :p
[04:21] <mjg59> If it's passed at install CD time, it'll be put on the installed system
[04:22] <Keybuk> we should probably decide whether we prefer pata_legacy/ata_generic or ide-generic
[04:22] <BenC> Keybuk: I meant so the user didn't have to add it manually after installing :P
[04:22] <mjg59> BenC: There /should/ be no cases where ide-generic is necessary
[04:23] <mjg59> Keybuk: pata_legacy = ide-generic. ata_generic = drivers/ide/pci/generic
[04:23] <mjg59> Just to make things confusing
[04:23] <Keybuk> heh
[04:23] <Keybuk> which did the latter get exposed as?
[04:23] <mjg59> generic.ko
[04:23] <Keybuk> ah yes
[04:23] <Keybuk> of course
[04:23] <Keybuk> pata_legacy has the bonus over ide-generic that it doesn't bind to ide0 or ide1 if there's a PCI device with those addresses
[04:24] <mjg59> Yes
[04:24] <Keybuk> (I wonder why ide-generic doesn't do the same thing)
[04:24] <mjg59> Because, erm.
[04:24] <mjg59> LOOK, A THREE HEADED MONKEY
[04:24] <BenC> mjg59: The case where we have a ide device with no driver (like marvell currently is in edgy/dapper)
[04:24] <mjg59> BenC: We should be using generic for that, not ide-generic
[04:24] <mjg59> That way they get DMA
[04:24] <BenC> generic needs entries in it still
[04:24] <mjg59> Not if ide-all-generic is passed
[04:25] <Keybuk> modprobe ata_generic all_generic_ide=1
[04:25] <Keybuk> (this can be trivially written into a modprobe.d options file)
[04:25] <mjg59> Anyway, we have a marvell driver for feisty
[04:25] <BenC> yeah, but I need to backport it for edgy and dapper
[04:26] <mjg59> Heh
[04:26] <mjg59> Or just add the entries to generic.c
[04:26] <BenC> might as well add the proper driver :)
[04:27] <BenC> Keybuk: Check this out:
[04:27] <BenC> "Also modprobe will be built into udev to solve the
[04:27] <BenC> performance-problems we see with parsing the modprobe-files for every
[04:27] <BenC> device with a modalias."
[04:27] <BenC> Keybuk: interested in building modprobe and udev together? :)
[04:28] <Keybuk> BenC: ref?
[04:28] <Keybuk> I've been bitching about that for some time
[04:28] <Keybuk> I even had a patch for it for a while
[04:33] <Keybuk> interesting how several people seem to be having the same idea entirely independently (user space binding)
[04:33] <BenC> yeah
[04:33] <BenC> I still think the idea of allowing the kernel to bind without interference is bad, forcing us to ubind/rebind
[04:33] <Keybuk> being able to just edit modules.alias, add a couple of new lines, and have things just work(tm) would be sweet
[04:34] <Keybuk> I still don't see how kay has managed to get bind/unbind to work
[04:34] <Keybuk> I have the SuSE rules here, and it doesn't use them
[04:34] <Keybuk> the biggest problem is the humongous race between udev getting the add@/module/... and the bind/unbind thing actually appearing
[04:35] <Keybuk> (not to mention futzing from a module to a driver)
[04:36] <Keybuk> if we had driver uevents, it would be a sinch
[04:36] <mjg59> * refs/heads/origin: does not fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6;
[04:36] <BenC> it would be nice if we could muck with the driver's table after it was loaded
[04:36] <mjg59> What does that /mean/?
[04:36] <Keybuk> SUBSYSTEM=="driver", ACTION=="add", some_thing_to_get_the_list_of_devices, SYSFS{bind}="$devices"
[04:37] <BenC> mjg59: It means that ubuntu-2.6 is not the same base tree as when it was in edgy...re-clone
[04:37] <mjg59> Grngh.
[04:37] <BenC> mjg59: we'll be syncing right along into 2.6.20, fyi
[04:37] <mjg59> Cool
[04:41] <Keybuk> BenC: so, thinking about this a bit more
[04:42] <Keybuk> the first step would be to at least get race and ambiguity free access to the bind/unbind bits of a driver
[04:42] <Keybuk> so when a module loads, or a device gets added to a bus, we can poke bind with the bus id
[04:42] <Keybuk> (I assume that overrides the table lookups?)
[04:42] <Keybuk> that way we could take advantage of it immediately by just excluding troublesome PCI ids, and having a udev rule to make the decision
[04:43] <Keybuk> if kay has nih'd my udev modprobe patch, this would be yawningly easy
[04:44] <Keybuk> (aside from the necessary kernel hacking)
[04:44] <kylem> moo.
[04:44] <Keybuk> (nvidia/nvidia-legacy, prism, etc. spring to mind as immediately useful test cases)
[04:45] <zul> kylem: open up a box of milk and won?
[04:45] <Keybuk> and that bt878 thing
[04:45] <kylem> i always win.
[04:46] <Keybuk> if we have success there, we can then just wholesale flip everything to use userspace for the binding
[04:48] <BenC> I have a bt878 card too, so I can test that case
[04:52] <Keybuk> right now we get uevents when a device is added to a bus
[04:52] <Keybuk> that uevent contains enough information to make a decision as to which modules can handle that
[04:53] <Keybuk> and probably also has enough information for us to decide which of two competing modules to use (e.g. we can look at a config file on the filesystem, if all else fails)
[04:53] <Keybuk> indeed, that is how we load modules today
[04:54] <Keybuk> we also get a uevent when a module is loaded into the kernel
[04:57] <Keybuk> the problem is we get this uevent at the wrong time, it appears to get generated before the module's init function is called
[04:57] <Keybuk> so before any of the module's drivers are registered
[04:57] <Keybuk> additionally, devices are bound to drivers, not to modules
[04:57] <Keybuk> and we get no uevents for drivers
[04:58] <Keybuk> also there's no way to get from a module to its drivers (just the other way around, due to a hacky symlink)
[04:58] <Keybuk> that'd be the first thing to fix
[04:58] <Keybuk> 1) get from module to drivers and back again easily
[04:58] <Keybuk> 2) uevents when drivers are registered and unregistered
[04:59] <Keybuk> this patch would be sufficiently subtle and useful that it'd probably get accepted
[04:59] <Keybuk> that'd give us the ability to write a udev rule that directly poked bind or unbind at the driver leve
[04:59] <Keybuk> +l
[05:21] <kylem> hmm.
[05:21] <zul> ?
[05:23] <Keybuk> definitely a conversation killer
[05:23] <kylem> so basically you want a uevent when the module is finished running it's init section?
[05:24] <Mithrandir> and the unload/finish section.
[05:25] <Keybuk> to be honest, I'd rather have uevents when the drivers were registered
[05:25] <Keybuk> that's far more fitting
[05:31] <mjg59> I wouldn't have thought that would be too difficult
[05:32] <kylem> Keybuk, i can try cooking a patch in my off time
[05:34] <Keybuk> mjg59: willy came up with the problem that modules register multiple drivers with the same name
[05:35] <Keybuk> so /sys/module/$MODULE/$DRIVER wouldn't work :-(
[05:35] <mjg59> Is kernel.org fucked right now?
[05:35] <mjg59> Keybuk: Yeah, there's going to have to be a bus component to it
[05:35] <kylem> mjg59, www1 is
[05:35] <kylem> use www2.kernel.org
[05:35] <Keybuk> kylem: I could probably argue for doing this in your on time, if you wanted :p  there's a spec for this
[05:35] <kylem> Keybuk, in that case, i'd like that
[05:36] <Keybuk> if drivers had kobjects that sat under the module, with the bus name salted in, that would rock
[05:36] <Keybuk> then /sys/bus/pci/drivers could be just a list of symlinks :p
[05:36] <Keybuk> https://launchpad.net/distros/ubuntu/+spec/new-pci-ids
[05:36] <jbailey> BenC: Around?
[05:36] <zul> hey jeff
[05:36] <jbailey> Heya chuck!
[05:37] <kylem> loadavg is like 500 on www1. heh.
[05:39] <Keybuk> (note that mdz's brain dump in the whiteboard utterly does not work)
[05:39] <Keybuk> for a start, his knowledge of module loading is a year out of date... modules.pcimap, sheesh, crusty!
[05:40] <kylem> i didn't realize it had changed
[05:40] <jbailey> kylem: Yeah.  Inthe new udev/sysfs world, there's some really cool hacks.
[05:40] <Keybuk> every ubuntu release up to dapper loaded modules differently
[05:41] <Keybuk> nowadays, the kernel generates a MODALIAS string (pci:vBLAHdBLAH...) that describes the device and places that in the uevent
[05:41] <Keybuk> that matches wildcard strings in the module alias table
[05:41] <kylem> ah.
[05:41] <Keybuk> so whenever we get a uevent with a MODALIAS, we just call modprobe on it
[05:42] <Keybuk> this is likely to change in feisty, or feisty+1, as udev is getting modprobe built in to save time
[05:42] <Keybuk> so udev will load the module directly
[05:42] <kylem> spiff. thanks.
[05:42] <jbailey> Byebye modules-init-tools finally?
[05:42] <Keybuk> given this, it'd be a piece of piss to do user-space binding if we can fix the issue outlined above
[05:43] <Keybuk> SUBSYSTEM=="pci", ATTR{vendor}="8086", ATTR{device}="1234", BIND="some_module"
[05:43] <Keybuk> some_driver, sorry
[05:44] <Mithrandir> Keybuk: what's the difference between a driver and a module?
[05:44] <Keybuk> Mithrandir: modules contain drivers
[05:44] <BenC> jbailey: yeah
[05:44] <Keybuk> drivers are per-bus, and contain tables of devices which they are bound to
[05:44] <kylem> multiple drivers, possibly...
[05:44] <Keybuk> e.g.
[05:45] <Keybuk> /sys/bus/pci/drivers
[05:45] <Keybuk> /sys/bus/pci/drivers/nForce2_smbus
[05:45] <BenC> for one, drivers don't always match the name of the module
[05:45] <Keybuk> /sys/bus/pci/drivers/nForce2_smbus/module -> /sys/module/i2c_nforce2
[05:45] <BenC> which for most modules really sucks
[05:45] <Keybuk> BenC: right, and sometimes modules have multiple drivers with the same name, just on different buses
[05:46] <BenC> yeah, the continuity there needs some help
[05:46] <Keybuk> that wouldn't be bad if the driver had a kobject under the module though, so we could do /sys/module/i2c_nforce2/pci -> /sys/bus/pci/drivers/nForce2_smbus or something
[05:46] <Mithrandir> Keybuk: ah, ok.
[05:47] <Keybuk> (that assumes a module doesn't contain multiple drivers with different names on the same bus ... I suspect there's an example of that too <g>)
[05:47] <BenC> if it's possible, I'm sure we have it :)
[05:47] <mjg59> Keybuk: Yeah, it may have to be /sys/module/i2c_nforce2/pci/i2c_nforce2 -> /sys/bus/pci/drivers/whatever
[05:47] <Keybuk> mjg59: which wouldn't be so bad
[05:48] <Keybuk> and at that point, you could just have /sys/module/i2c_nforce2/pci/nForce2_smbus/bind
[05:48] <Keybuk> and make /sys/bus/pci/drivers/* a symlink to /sys/module/$MODULE/$BUS/*
[05:48] <mjg59> Yeah
[05:48] <mjg59> Except in the cases where it's not a module
[05:48] <Keybuk> can you have drivers outside of modules?
[05:49] <BenC> Keybuk: would it be feasible for udev to have a mechanism with the kernel to where it could get a "add device" notification and somehow keep the kernel from performing binding on that device?
[05:49] <mjg59> Do statically built in things still appear under /sys/module nowadays?
[05:49] <BenC> Keybuk: Yeah, platform drivers for instance
[05:49] <Keybuk> of, of course
[05:49] <BenC> mjg59: No, which sucks
[05:49] <mjg59> Also, what Ben said
[05:50] <Keybuk> BenC: not sure it'd be worth the effort ... we could experiment at first by just removing duplicate pci ids, and doing the bind by hand from udev
[05:50] <Keybuk> it may make sense to have a /sys/kernel/never_bind or something
[05:51] <BenC> Keybuk: Do you know if the kernel sends an "device add" prior to binding with a driver?
[05:51] <Keybuk> BenC: it sends it before the actual bind, yes
[05:51] <Keybuk> but it's sent via netlink, so no knowing when udev actually gets to it, and gets to reply
[05:51] <BenC> does the kernel honor any sort of return values from udev?
[05:51] <Keybuk> no such thing
[05:51] <Keybuk> the kernel doesn't even know udev is listening
[05:52] <BenC> ok
[05:52] <BenC> it would be nice if we could export a driver->module mapping
[05:53] <Keybuk> yes
[05:53] <zul> pitty there isnt a kudev
[05:53] <BenC> as of now, it's only known after the module is loaded
[05:53] <Keybuk> zul: ?
[05:53] <Keybuk> KDE version?
[05:53] <BenC> in kernel udev!?!?
[05:53] <BenC> lol
[05:53] <zul> yeah
[05:53] <Keybuk> the whole point of udev is to do things in userspace
[05:53] <BenC> gudev, so that and try not to laugh
[05:53] <Keybuk> where we can make the big decisions, using things like config files and stuff
[05:54] <BenC> s/so/say/
[05:54] <Keybuk> ludev
[05:54] <Keybuk> pudev
[05:54] <Keybuk> ANYWAY
[05:55] <BenC> Keybuk: We need to get together on this whole driver binding thing to figure out the best way to do what I want with driver-module-manager
[05:56] <BenC> I really want to avoid the part where the kernel binds with "whatever driver" and requires udev to ubind/bind to the correct one
[05:56] <kylem> heh
[05:57] <BenC> I know it's a bit of a corner case, but without it, the whole idea of managing drivers seems pointless
[05:57] <BenC> and it also makes it harder to do things like driver updates from ihv's
[05:58] <BenC> there are cases where unbinding just isn't as nifty as it sounds
[05:58] <Keybuk> BenC: I agree
[05:59] <Keybuk> unbind-then-bind sucks
[05:59] <Keybuk> plus it just doesn't work atm
[05:59] <BenC> I need to test the bind/unbind
[05:59] <Keybuk> driver-module-manager?
[06:01] <Keybuk> the problem with unbind/bind is there's nowhere useful to do it right now, as you race
[06:02] <Keybuk> ideally when a device is added, we'd look up the driver it needs and which module that's in -- if the module is loaded, we'd poke the driver's bind directory -- if the module is not loaded, we'd load it
[06:02] <Keybuk> and then when a driver is added, we'd iterate the bus looking for any devices we can bind to it, and do the binding
[07:37] <zul> heh http://www.patentstorm.us/patents/7028023-fulltext.html
[08:26] <zul> has anyone tried building the vmware modules on 2.6.19 besides ajmitch
[08:28] <zul> meh...ill give it a shot tonight
[08:36] <BenC> lrm is built against 2.6.19, but there's a small fixup needed
[08:36] <zul> ill try sending a patch..
[08:36] <zul> or wait until vmware sends one
[08:37] <ajmitch> BenC: like? I'm wanting vmware server running again, it had issues with CHECKSUM_HW
[08:37] <ajmitch> is the same problem in the vmware player modules?
[08:37] <zul> CHECKSUM_HW has disapeared in 2.6.19 if i recall
[08:37] <BenC> s/CHECKSUM_HW/CHECKSUM_COMPLETE/
[08:37] <BenC> that's the fixup I was talking about
[08:37] <zul> ill send you a patch
[08:38] <ajmitch> ok
[08:50] <ajmitch> BenC: thanks, it's working now (once I removed a reference to config.h as well)
[08:51] <BenC> yeah, that's the other one
[09:42] <zul> kylem: for that hang on amd64 im working on an update