=== macd_ is now known as macd [00:05] philsf: it's a question of the behavior when turning on filesharing for the first time, when packages get auto-installed for you [00:05] so a proper test should involve removing the libpam-smbpass package (I think that's the only one) [00:06] slangasek: I did it, and couldn't reproduce the bug with a guest allowed share [00:06] sec, let me review the bug [00:06] I did purge samba-common and all of its rdepends and logged out to make sure I had a fresh environment, but the shares are in fact created after the installation of samba and libpam-smbpass, and they work without a logout/login cycle. I tried this more than once, in two boxes, both with Hardy. [00:07] philsf: purging samba-common probably doesn't remove you from the sambashare group, if you were previously added to it :) [00:07] NCommander: what's up? [00:08] slangasek: that's probably it, but why isn't the group removed? [00:08] philsf: the second part of the behavior only applies to non-guest shares [00:08] philsf: because removing guests is wrong, generally [00:08] removing guests? or groups? [00:09] cjwatson, any idea what voodoo will be needed to fix the current d-i/ARM builds? [00:09] NCommander: nothing, wait for the current kernel upload to build? [00:10] I already spoke with rtg about it and it looks like he took that into account [00:10] Ah [00:10] Cool [00:25] slangasek: you were right about the group, the package in -proposed works for me. I'm confirming the bug as soon as I test in the second machine [00:25] great, thanks! [00:25] no, thank you. bye [03:45] tkamppeter_, i was wondering. is there a particular reason that "Show printers shared by other systems" isn't enabled by default in the gnome printer tool? === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair [06:09] good morning [06:11] hi dholbach [06:11] hi LaserJock, hi warp10 [06:12] morning dholbach! [06:18] cody-somerville: what do you think about bug 311571? [06:18] Launchpad bug 311571 in gnumeric "gnumeric-doc should be a depends for gnumeric in Xubuntu" [Low,Triaged] https://launchpad.net/bugs/311571 [06:18] I've been somewhat annoyed by that one in the past [06:24] seems kind of odd to have ${Upstream-Version} on Conflicts [07:39] Good morning === tkamppeter_ is now known as tkamppeter [07:49] superm1, "Show printers shared by other systems" isn't enabled in s-c-p because it is not enabled in CUPS. pitti, why do we not enable to accept broadcasted CUPS queues from other machines by default in CUPS? [07:51] superm1: hard to say really, it's full of comments about 180 [07:51] superm1: I don't have a problem with letting 180 move to -updates, since it's completely new [07:51] superm1: but so far I didn't see a clear statement that the new 178 works [07:52] tkamppeter: we discussed that in the past, and the prerequisite for that is to change KDE and GNOME to clearly tell apart automatically detected from manually configured printers in the print dialogs, so that you can't lure someone into using a bad printer (or at least it's more obvious) [07:53] pitti, are bugs reported to KDE and GNOME? [07:54] tkamppeter: not sure, I don't think I filed them [07:54] superm1, ^^^ [07:55] pitti, can you do so, otherwise the developers of the dialogs are not aware of the problem. You must report to GTK and Qt, as they provide the currently used dialogs. [07:56] okay [08:07] pitti, thanks. [08:14] dholbach: thanks for your comment on bug 126988, but I don't understand why that is happening. Revisions 735 to 737 introduce quite substantial changes, and Launchpad shows me them in the web interface. Are you sure you have the right branch? [08:14] Launchpad bug 126988 in gnome-user-docs "Incorrect text to add logout (exit) button" [Low,Confirmed] https://launchpad.net/bugs/126988 [08:15] dholbach: from the diff you've posted, it doesn't look like the package even has the right version number, I bumped it to 2.24.1+svn20090109ubuntu1 in revision 736 [08:16] mdke: my mistake - sorry [08:17] dholbach: ok! No worries [08:17] dholbach: happy 2009 by the way [08:18] mdke: and the same to you :) [08:29] mdke: uploading [08:29] ... which might take a bit of time :) [08:30] dholbach: great, thanks === thekorn_ is now known as thekorn === asac_ is now known as asac === seb128_ is now known as seb128 === foka__ is now known as foka [10:52] hi [10:53] how could i do to redirect a pipe in a socket in both writing and reading ? [10:53] a pipe is one-way only [10:54] whatever you write to it comes out the reading end [10:54] it's not possible to read and write from the same end [10:54] if you want to do that, you need a socket [10:54] in fact i want to do a command like this : cmd1 | cmd2 but cmd1 and cmd2 on two diffrent PC [10:55] cmd1 | ssh otherhost cmd2 ? [10:55] in fact i have to write a bash-lite [10:55] so i can't use ssh [10:55] "have to write"? [10:55] my problem is i don't know how to read on the server from the client [10:55] you're not really explaining what your are trying to do, and I believe what you are trying to do has little to do with Ubuntu development. [10:56] this is sounding a bit like a homework question ... [10:56] yes [10:56] unix homework [10:56] don't ask those here, please. This is a working channel. [10:56] rmcbride: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html [10:56] where could i ask it please ? [10:56] rniamo: Try: ##linux. [10:56] rniamo: that really isn't our problem; ask your teacher if you need help [10:57] we're not here to help people pass their CS homework [10:57] (most of us never passed *our* CS homework) :p [10:57] Keybuk: we didn't? [10:57] Speak for yourself [10:57] I know I did [10:57] i passed the fun bits [10:57] i just want some help, sorry if it is the bad chan [10:57] Sockets programming isn't exactly fun, but it is interesting [10:57] rniamo: check out netcat [10:58] StevenK: I find it fun [10:58] rniamo: it does something similar [10:58] netcat ? [10:58] rniamo: yes. Ask Mr. Google [10:58] Keybuk: You wrote a replacement for init, this makes you a masochist. [10:59] my problem is that socket are ok, pipe are ok but not both together [10:59] * directhex ports init to ironpython [10:59] StevenK: I prefer other people to inflict the pain ;) [10:59] cjwatson: Did you follow the jaunty-unr discussion at UDS? [10:59] rniamo: right. netcat communicates via sockets [11:00] my problem is here http://paste.linuxassist.net/169910 [11:00] i would like to add a close(0); dup(cbCmd->sock); [11:00] cjwatson: Essentially, -umpc goes away, and -netbook-remix turns up. I have a uncommited branch in the mobile seeds for this, but it also requires the task name to change, which I recall you saying needs tasksel changes. I looked at tasksel, and I ran away screaming ... [11:02] ugh [11:02] cjwatson: Also, I'd like you to sanity check my commit, because I'd like to grow a ship seed, but the one that is in ubuntu.jaunty is perfectly fine. [11:02] random sleep statements in cron.daily makes Keybuk unhappy [11:22] StevenK: unr> no, I didn't [11:22] StevenK: where's your branch? [11:22] cjwatson: I'm pushing it to a seperate location right now. [11:22] StevenK: tasksel updates are trivial as long as you realise that almost all of the interesting stuff for us is autogenerated by ubuntu-seeds.pl [11:22] and that you *must* *not* *touch* ubuntu-tasks/ by hand [11:23] cjwatson: Yeah, I looked at ubuntu-seeds.pl source and then decided the best step would be to talk to you. :-) [11:28] cjwatson: My branch is at sftp://chinstrap/home/stevenk/mobile.jaunty [11:33] pitti: ping [11:35] can somebody besides pitti tell, why i cannot find a debug package for "mairix"? [11:35] wow [11:36] just applying the "no legacy ptys" change to the kernel config reduces the average pid by ~1000 [11:36] not surprising, but shows just how much we did just for them [11:36] ccm: http://ddebs.ubuntu.com/pool/universe/m/mairix/ [11:36] actually [11:36] by ~2000 [11:36] because I forgot, each legacy pty had two kobjects [11:36] which means two udev processes per kobject per trigger [11:37] we trigger twice [11:38] cjwatson: thank you. is it normal that i cannot install this directly via aptitude? [11:40] ccm: you would have to add an appropriate line to sources.list [11:40] that is normal [11:43] thought I'd that and the dbg package is not listed in packages.ubuntu.com either, but anyway, i can work with the url [11:43] thank you very much [11:44] ccm: what cjwatson said; see https://wiki.ubuntu.com/DebuggingProgramCrash [11:44] for instructions [11:45] packages.ubuntu.com only looks at the main archive [11:45] pitti: hallo mighty pitty \o/, any plans to merge newest debhelper? :) [11:45] debug symbol packages are intentionally in a separate archive [11:46] sebner: by default I'm not chasing any merges any more, unless someone asks me with a good reason :) [11:46] pitti: csharp support for licensecheck \o/ (Asked by me in Debian also) ^^ [11:48] pitti: Oh, I wanted your opinion on bug 312659? [11:48] Launchpad bug 312659 in kfreebsd-5 "Please remove kfreebsd-5 from Jaunty" [Wishlist,Confirmed] https://launchpad.net/bugs/312659 [11:49] "Use the bug subscription, Luke!" :-) [11:49] pitti: we didn't have retracers running for over a month apparently, do you plan to work on those or should I look at that (I'm busy updating GNOME but I can try to have a look this week)? [11:49] StevenK: will look in a minute [11:49] seb128: that's on my TODO list this week (get jaunty retracers up and running, and care for the other ones) [11:49] seb128: yesterday I fixed the client side apport stuff, now I'm ready to work on the server side [11:50] pitti: ok thanks, I will let you do that then, I've lot of catching up to do on GNOME [11:50] * seb128 hugs pitti [11:50] * pitti hugs the Gnominator [11:50] sebner: ok, can do [11:51] pitti: \o/. besides I think there are a lot other cool improvements since there are some versions between actual ubuntu and actual debian version [11:51] StevenK: looks fine to me [11:52] pitti: Yeah, I think it needs to be shot, too, but wanted to check. As well as wondering if the blacklist can deal with wildcards [11:53] StevenK: wildcards> not as far as I know [11:54] I would doubt it [11:55] That's going to be fun to sort out, then. [11:55] I'll remove it and db4.3 tomorrow [11:55] StevenK: why? blacklist is source based [11:56] pitti: Exactly. Just depends how much source packages we're talking [11:56] so you don't need to care about the bazillion binaries [12:05] pitti, well i've got a large variety of hardware (including that machine I brought to UDS) working with 177.82 that i've been using since 177.82 was released. I was one of the original folks affected by it's original bug reported to NV (The long suspends). I'll add a comment to the bug. [12:10] superm1: thanks; so if you give your ok on the bug, and there aren't any reports about regressions, this is good to go [12:10] (sorry if that came through twice, I got disconnected) [12:10] pitti, okay great thanks [12:11] in the future need to make sure these bugs dont get hijacked by new releases so they are easier to discern and track [12:13] tkamppeter: I filed cups bug 3052, which is a prerequisite for changing the gtk/qt print dialogs [12:13] tkamppeter: I just discovered that cups doesn't actually seem to tell locally configured vs. autodetected [12:14] sebner: sid has 7.0.17, jaunty has 7.0.17ubuntu1 ? [12:15] pitti: ARGH. sry. I mean devscripts. sry sry sry [12:15] sebner: ah, ok; I just looked at the experimental debhelper, and that seems a bit delicate to merge [12:17] pitti: heh, don't worry. I'm only interested in devscripts from sid :D [12:17] sebner: that's a rather complicated merge; unless you beat me to it and do it yourself, mind to send me an email about it? I won't do it right now [12:17] or do you want to prepare and test the merge yourself? [12:18] pitti: I'm afraid that I won't have time besides that's stuff for pros like you :) Just do it anytime you have time and passion for it =) [12:20] StevenK: you sure that inheriting from ubuntu.jaunty (rather than platform.jaunty) is a good idea? you've given the live seed different inheritance than it has in ubuntu.jaunty, which is a bit ... interesting [12:20] though I suppose technically feasible [12:20] StevenK: have you run this through germinate to look at the result? [12:21] StevenK: no netbook-remix-dev? [12:21] mobile-dev is dead [12:21] pitti: ping! :) [12:21] Baby: hello [12:21] cjwatson: We don't need it and decided it was time to kill it at UDS. [12:22] ok [12:22] cjwatson: platform.jaunty doesn't have ship. [12:22] pitti: :) [12:22] StevenK: but ubuntu.jaunty's ship inherits from desktop [12:23] cjwatson: I suppose I can drop live from mobile.jaunty's STRUCTURE, and it will sort it out? [12:23] StevenK: did you consider whether you would be better off writing your own ship seed? [12:23] StevenK: do you want live or ship-live? [12:23] I'm not entirely clear on what you actually want, which makes it hard to advise :) [12:24] cjwatson: Oh, right. We want the list of packages that are included as .debs on the Live CDs [12:24] that is NOT ship, it's ship-live [12:24] Which I think is ship-live [12:24] very important to be clear on the distinction [12:24] what do you want in the live filesystem? === racarr_ is now known as racarr [12:25] and do you really want all the stuff that's in ubuntu.jaunty's live and ship-live? [12:25] I wouldn't have thought you'd want ndiswrapper or ISDN utilities, for instance [12:25] Well, from this seed base, either mobile-mid or mobile-netbook-remix plus casper and ubiquity [12:25] nor that you would necessarily want the same language packs [12:26] could a sponsor for main look at bug 254790? It blocks some dietlibc fixes I'd like to upload. [12:26] or even perhaps the same filesystem support [12:26] Launchpad bug 254790 in binutils "strip segfaults on dietlibc-built executables" [Unknown,Fix released] https://launchpad.net/bugs/254790 [12:26] StevenK: it sounds to me as if you should inherit from platform.jaunty and write your own live and ship-live seeds, just as e.g. Kubuntu does [12:26] cjwatson: I said the same thing in the session, and persia talked about threatning to find a MID form-factor device with ISDN. :-) [12:26] otherwise you're going to end up with a bunch of junk you don't want [12:27] and you won't easily be able to control it [12:27] as soon as you want to control it, you're going to end up writing your own live and ship-live seeds anyway [12:27] * StevenK nods [12:27] so you might as well start out that way, I think [12:27] StevenK, I threatened to show you my CF ISDN card that I used on my Zaurus for connectivity for years, rather. [12:27] Yeah, makes sense. [12:28] also, if you need different shipped objects one of which is mobile-mid + live and one of which is mobile-netbook-remix + live, you're going to need two live-a-like seeds (and ship-live-a-like, presumably) [12:28] but you can perhaps worry about that later [12:28] So fix that, commit that, fiddle with mobile-meta and upload it, and then prod you to fix tasksel? [12:28] persia: Woot, two technologies I hate in the same device, Compact Flash and ISDN. [12:29] this is because a seed can only be germinated against a single set of ancestor seeds, and if you germinate live to inherit from netbook-remix and then try to use it with mid, you may well end up with missing dependencies [12:29] StevenK: yes. Note also that your branch doesn't seem to be up to date with current mobile.jaunty [12:30] Mmmmm [12:30] so you'll need to merge into mobile.jaunty rather than just pushing over the top [12:30] cjwatson: It isn't, on purpose [12:30] well that's a bug :) [12:30] don't lose history even if you want to revert it [12:30] cjwatson: Oh, it's from the same base, so it's under control [12:31] fix the things I mentioned and push again, then I can have another look? [12:31] Hm. I unbound, commited and push. Now what do I do ... [12:31] commit and push again? [12:31] (what are you trying to do?) [12:32] Trying to figure out how to resurrect {,ship-}live [12:32] 'vi live' [12:33] or are you trying to make it have the same file-id as the corresponding files in ubuntu.jaunty so that you can merge? that may not be necessary [12:33] I'm trying to get the old files back [12:33] what old files? [12:33] in what branch? [12:34] the live and ship-live seeds haven't been in mobile.jaunty since r1310 [12:34] {,ship}live used to exist in mobile.{intrepid,jaunty} [12:35] Yup, those are what I'm trying to resurrect, since they probably have most of the right content [12:35] so, firstly, you *could* just re-add them afresh; essentially the only thing that will break is merges from ubuntu.jaunty, which are not that important anyway [12:35] however, it is *slightly* more elegant to have them share a file-id I suppose [12:35] bzr revert ship --revision 1310 ? [12:35] Err. --revision=1310 [12:36] Ah, that would be the magic [12:37] oh, that works, I was going to suggest get -r1309 and add --file-ids-from [12:37] but persia's approach is shorter [12:37] also, -r1309 not 1310 (1310 is the revision that removed them) [12:37] Oh, right. [12:37] Also probably want to use the correct filenames. [12:37] Yeah, I remembered that, and s/10/09/ before running [12:37] I did that too [12:38] * StevenK waits for bzr push [12:38] cjwatson: Pushed [12:39] cjwatson: I didn't change what live inherients from, since I'm still unsure about that bit. [12:52] pitti, CUPS is already capable of telling whether a queue is locally defined or picked up from a broadcast. CUPS queues have a CUPS_PRINTER_DISCOVERED bit set then. See /usr/include/cups/cups.h, enumeration cups_ptype_e. [12:53] sure [12:54] cjwatson: udev has the same need [12:54] we load modules, but want to silently succeed as cheaply as possible if the module is a built-in [12:54] apw: http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/ubuntu/revision/104, http://bazaar.launchpad.net/~ubuntu-core-dev/mdcfg/ubuntu/revision/1072, and http://bazaar.launchpad.net/~ubuntu-core-dev/partman-md/ubuntu/revision/909 are all bodges around this same problem [12:54] apw: the second and third are sane enough actually, but the first is a good illustration of the difficulty [12:55] (the second and third were patches for real installer bugs TBH; it was using has-the-module-been-loaded-yet as a key for rather too much initialisation code) [12:55] ok so why can't we just modprobe, ignore the result [12:55] and then try and use the functionality and blow up then if its not there? [12:56] the installer tries to support a variety of kernels fairly cleanly, partly because of custom kernels (people do in fact do that quite a bit) and partly because the kernel keeps changing under us :) [12:56] and it's much better to be able to report "this facility is unavailable" rather than "thingummyflop blew up with ENOSYS" [12:56] (or EINVAL more likely I guess) [12:56] right, but is not the test in #3 there actualy a 'do we have the function' [12:57] that should be after an ignored modprobe [12:57] probably best look at #1 instead [12:57] the module_probe function there is a wrapper for something that tries to load the module and otherwise fails with a red-screen [12:57] the difficult bit is telling the difference between "module is built-in" and "module is missing" [12:57] and the bodge is that I've had to incorporate a check for whether the function is present [12:58] right, you've done what i am saying [12:58] which is, frankly, a pig to do sometimes; it's not easily possible for dm-round-robin without actually setting up a hardware round-robin multipath, for instance [12:58] just i think you should probe the modules as well [12:58] and ignore any failure [12:58] so it works either way [12:58] I think that would be a straightforward regression in the installer's ability to report errors [12:58] it would fall over much later with a much more obscure error [12:59] not if you do it like [12:59] if ! dmsetup version; then [12:59] modprobe foo || true [12:59] if ! dmsetup_version; then [12:59] ERROR [12:59] so how do I do that for dm-round-robin please? :) [13:00] (I did look, quite hard) [13:00] well there is an issue [13:00] do you always know the kernel before hand? [13:00] and honestly, all this having to putz about with dmsetup is really clumsy [13:00] doesn't that defeat the object of building in in the first place [13:00] that code used to be 'module_probe dm-mod' [13:00] quick and easy [13:00] if it's more expensive to determine whether something is built-in than to load it as a module ? [13:00] right, I definitely want something as lightweight as possible [13:01] ... [13:01] so does the installer CD know the kernel its built with? [13:01] could we extract the information out of the kernel as we build the CD? [13:01] the installer CD might, but I'm not going to hardcode that knowledge into installer scripts! [13:01] so you _know_ [13:01] some of this code is run in contexts where that is not helpful [13:01] stupid kernel [13:02] it would be *much* *MUCH* better for it to detect; Keybuk's proposed modprobe option is *exactly* what I'm looking for [13:02] but modprobe simply cannot know [13:02] as things stand, either its =y or =n, but i don't know which [13:02] isn't the presence of the driver exposed in /sys? [13:03] also, BTW, it's not a matter of what the installer CD is built with; the installer loads udebs containing kernel modules into memory at runtime [13:03] that is true of some modules, but like crypto, does that appear as a driver? [13:03] the modular ones do [13:03] the non-modular ones *currently* don't [13:04] but we could just go back to building them as modules until that knowledge is available [13:04] though we'd still have the dm problem [13:05] well you may have a case to back those out if we cant get a sensible fix before JJ releases [13:05] one of the good things is that you have blown up now, before it set in stone [13:05] cjwatson: the presence of a driver is exposed [13:05] not the presence of a module [13:05] you don't pass driver names to modprobe [13:05] you pass module names [13:05] apw: indeed [13:06] module aliases may help here to convert back [13:06] Keybuk: I don't see e.g. dm-mod exposed anywhere in /sys [13:06] right, it wouldn't be [13:06] it's a subsystem [13:09] we do build in the config, into the kernel right? [13:10] so we can get it out in theory [13:11] are you thinking of CONFIG_IKCONFIG_PROC? [13:11] after boot, so we can reconstruct /boot/config-* [13:11] we have half of that turned on [13:11] the half that keeps the stuff in the on disk binary image of the kernel [13:11] i believe [13:11] I would echo Keybuk's comment that grepping a text file (kernel-generated or otherwise) for this is going to be slow [13:11] I have an amusing idea ;) [13:12] you could auto-generate a modprobe.d blacklist file [13:12] you could have /sys/config/FEATURE [13:12] present or absent [13:12] cjwatson, the code you have there is running a depmod -a [13:12] so any single additional grep is free by comparison [13:12] apw: who would own the list of config -> module name mappings? [13:13] that's only because it might have just loaded modules. The same consideration does not apply during boot [13:13] er by loaded modules I mean installed some udebs containing modules [13:13] that is also not the case in every installer context in question [13:15] Keybuk, i wonder if that is expressed in the kernel [13:15] apw: it would have to be [13:16] maintaining a kernel config (kernel maintained) to module name (kernel maintained) mapping outside the kernel is not exactly a plan made of awesome [13:17] from the modprobe pov. we simply need a list of module names that we can silently succeed because they have been built-in [13:17] yeah, I'm not keen on having to name the feature in installer code either [13:18] from my POV the config feature name is a kernel implementation detail that might change at any time; the module names are at least a little more persistent than that [13:18] and none of it is obvious in the source [13:19] implementing the "succeed silently" in modprobe is easy [13:19] we just make the module name an empty alias [13:19] the hard part is getting that list [13:19] could that be exported via depmod then [13:19] so modprobe dm-mod would be equilent to just modprobe "" [13:19] ? [13:19] cjwatson: yeah, I'd append it to modules.alias [13:19] the hard part, as apw says, is getting that list [13:20] what if we did a hybrid approach [13:20] you tell us which modules you are using and somehow we work out the config [13:20] options they represent [13:20] apw: from a udev point of view, everything ;) [13:20] apw: that's really tricky in general, that installer code is dynamic, synced/merged from Debian, etc. [13:21] perhaps that could be kept with the config info so it would be kept up to date [13:21] where does the information that goes into modinfo come from? [13:21] cjwatson: the modules themselves [13:21] it's a section in the .ko that depmod reads [13:21] Keybuk: right, but I mean where in the kernel source [13:21] what's the macro that does it [13:21] or struct or whatever [13:21] the module alaises, are complex [13:21] there are some magic programs which mush it about to make them [13:22] from some of the other structures in the kernel [13:22] actually, that's an interesting point, we'd need the modaliases of the modules that are built-in too [13:22] just been looking at it for MMC [13:22] but at least it is in the C files and not just in the Makefiles [13:22] otherwise we'd waste a lot of time [13:22] which means the problem is tractable [13:22] but you can't tell from the foo.c what the .ko is called [13:22] you just need to make MODULE_* do something useful for built-in drivers [13:22] oh, that is only in Makefile? [13:22] bah [13:22] the name of the module is only in the Makefile [13:23] apw: what happens to MODULE_DEVICE_TABLE for the kernel? [13:23] in fact, can you extract MODULE_* at all for built-ins ? [13:23] there is a a script which converts that into specific format MODULE_ALIAS entries [13:23] you'd have to put a section in vmlinuz that's later stripped [13:23] I think [13:23] which are then compiled and linked with the .o to make the .ko [13:24] apw: yeah, but where do they go when you link the .o into built-in.o ? [13:24] hrmm, you mean is there one in vmlinux [13:24] that we are not looking at [13:24] that's what I mean, yes ;) [13:24] when i was looking at depmod (a long time ago) i think it did read and skip vmlinux for most things [13:24] so it might be in there [13:25] __MODULE_INFO is an empty macro for built-ins [13:25] * apw needs a module which is built in [13:25] unix [13:25] right now, the information is not in the .o files that get linked into built-in.o [13:25] but it could be if you mucked about with moduleparam.h [13:25] yeah, so there is no equivalent [13:25] well you'd need to modpost vmlinux too [13:26] well, I didn't think it could be done entirely without kernel changes, certainly [13:26] cjwatson: the other problem is the kernel developers got clever with Make [13:26] but I was wondering if there was a relatively lightweight set of changes possible [13:26] so the only difference between a .ko compile and a .o one is just whether some variable is y or m ;) [13:26] obj-y += something.o [13:26] vs. [13:26] obj-m += something.o [13:26] yeah, I know [13:26] MODULE is defined for obj-m, though [13:27] * Keybuk can't remember where the ko names are defined [13:27] ok lets look at it the other way round [13:27] we have a probe point 'module_init' [13:27] right now when we load one it makes /sysfs/module/ [13:28] perhaps we could hijack that and have a /sys/build-in/ appear [13:28] couldn't we just have a /sys/module/ for built-ins? [13:28] hm, excuse me, baby needs feeding [13:29] I guess you wouldn't do that actually, because the kobjects would be different [13:29] but /sys/built-in/ would be nice [13:31] apw: actually, where *are* module names defined?! [13:31] * apw is looking at that right now [13:31] there is a MODULE define floating about [13:37]