login
Search
Hi all,
I would like to see some changes for the way the default configurations
are handled. We currently have a lot of small variations between GENERIC
and GENERIC_LAPTOP on i386 and I expect most development e.g. of PCI
drivers to happen on that platform or at least to be tested on it.
When new PCI drivers are added, changes are high that *other* platforms
are even less like to get all entries than GENERIC_LAPTOP to stay in
sync with GENERIC.
My suggestion is that all MI drivers for PCI, Cardbus, USB and PCMCIA
(devices, not necessarily controllers) are collected from i386 and
amd64's GENERIC kernels and added to
src/sys/conf/std.{pci,cardbus,usb,pcmcia}. The direct lists of i386 and
amd64 kernels will refer to those with a possible exception for space
limited install kernels. Other platforms should be converted by the
portmaster.
xtraeme@ volunteered to work on this if we have a consensus. Let's get
this maintainance nightmare sorted out.
Joerg
I have three comments about that:
- I'm not sure maintainance will be any less nightmarish. While
doing the "no <instance>" stuff in config(1), I discovered that it
doesn't bring much. Commenting out and negating is about the same.
- Adding a driver which, while MI, is actually rather MD will have
side effects on other archs. This is both positive and negative,
and should be kept in mind.
- It will be much, much, more difficult for the user to wire down a
configuration. IMO, doing this implies that we (the project) rather
strongly discourage home-grown kernel configurations.
The last point is important to me: if we do this, we might as well
change the syntax for something much more flexible (like, say, a markup
language rumoured to be extensible, or a subset of it, for which we have
a parser).
--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
Not having to modify 20 kernel configs for random architectures is a I'm talking about things like network devices. I see no valid reason why a PCI architecture should not have all PCI cards. Most of them can be obtained in some form as extension module. Even e.g. the Intel wireless chipsets are present mini PCI cards that are not bound to i386/amd64. There are some possible exceptions, e.g. HPET makes no sense in such a file even though it is in dev/ic. I never that all devices must be I disagree on this. If you go by the original list, e.g. for a server you would comment out the include for cardbus and PCMCIA. You inline the USB and PCI fragments you are interested in. That is not that much more work than hunting down the rather long list we currently have. Also note that moving the common devices out makes it easier to distinuguish GENERIC and GENERIC_LAPTOP for example, so the user has a I don't think flexibility is really the problem here... Joerg
I suggest a tool for flattening the config file, usage e.g. config -f GENERIC > MYCONF That way you could also comment out the inclusion of, say, cardbus from the config file before flattening it and get a much more trimmed-down version without extra goop and a "no cardbus" statement. This might be at least slightly better for usabilty? Dunno how much work that is, but I assume negligible for someone who IMHO we should discourage home-grown kernel configs, but OTOH we can't exactly do that today, tomorrow, or even next week and still have everything work. However, would be nice if the project set a policy for moving towards this (or moving away from it, if so decided). --=20 Antti Kantee <pooka@iki.fi> Of course he runs NetBSD http://www.iki.fi/pooka/ http://www.NetBSD.org/ "la qualit=E9 la plus indispensable du cuisinier est l'exactitude"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Hmm, that would be a little more complex I think - you probably don't want to expand files.pci for instance. Maybe include statements need a We can't really do that without much better LKM support, as in most drivers being available as modules which can be loaded and unloaded on demand. have fun Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBRuLjd8pnzkX8Yg2nAQKT/gf/TsZZxMj2+Lb1dKbUx7gzj306PRuaOjdx EGp44nQjJJopSamSmSTaCelFgLXZ2S+2SL7X7p1HhByOMlhpA9Tws0ATIvBiH6ug CB5uHBQU6Mo7bOwJA34RpwRvvSlyfOPX5NjtDmpccHTsGeJ85/NZxUPgCQqq+gL+ yuCC+/SmMTYskZuNrS5cTbVkZphcAdgBO2xNAHOJ264BEsGq6TRaXzdgWm+Bf3TV MSUwoU6/1ij/GEwO3guVdAlRxYQku9WbdQAQk9ysuVuGNrBSa1ScMYnkhdBVkcPG NyC6m4KEPGpzusra5wyhQMjhrX8U1WwkZw9UdUcppNeupG7z7Gb3GQ== =JJ+J -----END PGP SIGNATURE-----
files.pci isn't "include"'d in GENERIC. .. Unless I'm missing something, which very well might be the case. Exactly. I am thinking we won't have that support even by next week. --=20 Antti Kantee <pooka@iki.fi> Of course he runs NetBSD http://www.iki.fi/pooka/ http://www.NetBSD.org/ "la qualit=E9 la plus indispensable du cuisinier est l'exactitude"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like this idea. We can create generic include files for isa, cardbus, pcmcia, ipv6, wscons, smb etc.. functions and include them in every architecture GENERIC kernel config file. When somebody want to create own kernel config file "config -f GENERIC > MYCONF" will Regards - ----------------------------------------- Adam Hamsik jabber: haad@jabber.org icq: 249727910 Proud NetBSD user. We program to have fun. Even when we program for money, we want to have fun as well. ~ Yukihiro Matsumoto -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG5QDslIxPgX3Go0MRAikdAJ45+ZdgJL2OaTrYd6R0/22pNzqT0ACgljB/ w0EswuEHZEmPnBl/PolDWUo= =HY8A -----END PGP SIGNATURE-----
On Sat, Sep 08, 2007 at 08:46:55PM +0300, Antti Kantee wrote: Then it would be much harder to run NetBSD on some machines where disabling pci cards in a notebook case saves a lot of space. And no, you (I don't mean Antti) don't need to tell me to buy a bigger memory module. Splitting out the GENERIC kernel config makes it not easier to track what was added, because you now need to track a few more files after a cvs update. Right now I include the GENERIC kernel and disable deivces, where I have a copy of the GENERIC file to compare it after the cvs update is done. Bernd
--F20q8ig/xCX9TrYX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 08, 2007 at 08:46:55PM +0300, Antti Kantee wrote: See what's attached. I could make locators prettier. Strangely enough, repeatedly running config -f on GENERIC doesn't converge; it loops over 6 occurrences. That wouldn't happen if I ordered stuff in a more logical manner, of course. --=20 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org "You could have made it, spitting out benchmarks Owe it to yourself not to fail" Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005. --F20q8ig/xCX9TrYX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config-f.diff" Content-Transfer-Encoding: quoted-printable Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /pub/NetBSD-CVS/src/usr.bin/config/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- Makefile 13 May 2007 20:22:45 -0000 1.8 +++ Makefile 15 Sep 2007 15:24:49 -0000 @@ -4,7 +4,8 @@ .include <bsd.own.mk> =20 PROG=3D config -SRCS=3D files.c gram.y hash.c lint.c main.c mkdevsw.c mkheaders.c mkioconf= .c \ +SRCS=3D files.c flatten.c gram.y hash.c lint.c main.c mkdevsw.c \ + mkheaders.c mkioconf.c \ mkmakefile.c mkswap.c pack.c scan.l sem.c util.c =20 .PATH: ${NETBSDSRCDIR}/usr.bin/cksum Index: defs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /pub/NetBSD-CVS/src/usr.bin/config/defs.h,v retrieving revision 1.20 diff -u -r1.20 defs.h --- defs.h 13 Jan 2007 23:47:36 -0000 1.20 +++ defs.h 15 Sep 2007 15:24:49 -0000 @@ -366,6 +366,17 @@ struct ...
On Sat, Sep 08, 2007 at 06:41:39PM +0200, Quentin Garnier wrote: > On Sat, Sep 08, 2007 at 03:33:17PM +0200, Joerg Sonnenberger wrote: > > I would like to see some changes for the way the default configurations > > are handled. We currently have a lot of small variations between GENERIC > > and GENERIC_LAPTOP on i386 and I expect most development e.g. of PCI > > drivers to happen on that platform or at least to be tested on it. > > When new PCI drivers are added, changes are high that *other* platforms > > are even less like to get all entries than GENERIC_LAPTOP to stay in > > sync with GENERIC. > > [...] If the issue is just keeping all the assorted GENERICs in sync, it's probably easier to set up some kind of automatic cross-checking. E.g., one could write a cron job that extracts all the pci devices from each GENERIC*, remembers the diffs among the lists, and mails out any changes that appear. I do think the size of configs is getting out of hand and some steps should be taken to allow them to be more concise (not just GENERIC, but also custom configs) -- but I think those steps are going to want to be larger and more comprehensive than what's been proposed, and I think it's important to take the time to work out exactly what configs should be going forward. I rather doubt there's widespread agreement. :-/ > The last point is important to me: if we do this, we might as well > change the syntax for something much more flexible (like, say, a markup > language rumoured to be extensible, or a subset of it, for which we have > a parser). Er, that would be less flexible, not more... -- - David A. Holland / dholland@eecs.harvard.edu
My suggestion is that all MI drivers for PCI, Cardbus, USB and PCMCIA
(devices, not necessarily controllers) are collected from i386 and
amd64's GENERIC kernels and added to
src/sys/conf/std.{pci,cardbus,usb,pcmcia}. The direct lists of i386
and amd64 kernels will refer to those with a possible exception for
space limited install kernels. Other platforms should be converted by
the portmaster.
I think this is broadly a good idea. It's a little disconcerting to
have ath* at pci* and ath* at cardbus* in separate files, but given that
we don't have to have ath* by itself and then bus glue, I think it will
be fine in practice.
I would further suggest splitting some of these into mainstream and
fringe devices, so that people can include them separately, but that
gets to be MD in practice. But it might enable omitting (on
e.g. sparc64) lots of stuff that's in practice only on i386 and is odd
even there.
With this, std.pci would include
pci.common
pci.uncommon
Is it really worth the trouble? I mean GENERIC is meant to work ~everywhere, so the only good reason to not include a driver is that it is either just broken (and who commits such drivers?) :-)) or that it conflicts with something else. I wouldn't want to make a popularity contest here. Do you actually partly modify a kernel config? If I go to that trouble, I normally do the correctly and trim down the kernel to the devices I have. Joerg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Sounds good to me - that would at least ensure that all MI drivers compile everywhere they make sense. And way too often people confuse 'drivers listed in GENERIC' and 'all drivers available' - I know I made that mistake ages ago. Why not go a step further and do the same for other MI kernel config bits? Like std.ipv6 ( all IPv6 related options ), std.smb ( everything you need for file-system SMBFS ), std.wscons ( all wscons options and wsdisplay, wskbd, wsmouse etc. attachments ) and so on ? have fun Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBRuLh8spnzkX8Yg2nAQKYUwf/T0KmAl1AgJJ2dpRc/SOQJ6OBmVB9dMX9 9Tk159B0Z05qY7J6FZQ5DYZRxktVKdsaUvOIFKR7uTC3uK5Dz+Suu6N/fhLMPW+J J0I5X4W0v/ta2DJr62xSvd23BlMamH56eDBfcVixu/STS3o/CkEAIwfnMFRGIAHX YvJoDwGREAcYUjHVNxsvqDQux6mg/RlSlxmxZ9M6kw6ZxX1Do8T7FiK5YuGkZxc5 TAK3Tv/sU+JdxCTyHTedNEKZEnkag6a5zwIWWzRLcZ6sgGtbr0oiV42jUoVfBO09 pZTThY5h3UZlOzmfOGRuQXP91cxF34MNKnA8286v7YmpVbkOqwjw0Q== =jedG -----END PGP SIGNATURE-----
Given that a common use case is "What hardware works with GENERIC" and They tend to change a lot less often. That might also really fall into the category of making it harder to tune the system without good reason. I just want to start somewhere :-) Joerg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, macppc's and sparc64's GENERIC contain far fewer MI PCI, audio, cardbus, PCMCIA etc. drivers than for instance i386, in those cases assuming if it's not in GENERIC it's not there is a mistake, it would just indicate that the drivers in question likely haven't been tested on those platforms. Same about sparc and pcmcia - only a handful drivers are in GENERIC Well, I'm likely to have either all ipv6 bits or none, either all smb bits or none etc. but that's probably just me - all I say is an easy way to turn off - say, ipv6 - completely without having to hunt down every single related option might be useful. have fun Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBRuMWKcpnzkX8Yg2nAQJHlAf+I8LUYKpCWsoq9keDiLn/iJNeZR1T8lJ4 DQ0Ecs4GI2eofJoTe8E+7IivwKYZmJIir2wYXjAnQYdtXrevWOgZQ8Zt8/8vK5wa fEy2xX1wJcuepYMZtBlV61/g42lZ7sjc+CArnhXCfntX7/QhJZvzMFty0Gyp1UE8 CgTIkgJXWD43cn4hApbooC2HogR9G7vgxvhSh09iDmiS2r05iMrVGUQ7oIfkQ53l iqvrQ6/RonPVzkHDMCmAE+l5bqLBgfKo8dZmNwQb4/VgvyFXW+UhqqxNwIyWacVF VuU3vfcKUCdyVtb8vBW1fQAYHHQ4xAXJjJPWiDBSdkQlb1YnJ6SgQw== =FGvd -----END PGP SIGNATURE-----
This is a bigger point that you might imagine... I found when working on PowerPC and ARM systems that drivers that have not been used on sparc/macppc/alpha/etc., probably don't work on other architectures. The reasons have been mentioned elsewhere in this thread. I say "probably" because in my experience, each of a half-dozen or so drivers that I tried needed a tweak here or there when I put them in a PowerPC (BE or bus_dmamap_sync) or evbarm (bus_dmamap_sync) system. None of the problems that I saw would be caught by a compile--only by trying to use the hardware. I don't have a real problem with including devices in a compile, but making the leap to "supported" or "expected to run" would be unconscionable. If we do include them, how do we communicate (amongst ourselves and with users) which drivers have been actually used successfully on a given platform? -allen -- Allen Briggs | http://www.ninthwonder.com/~briggs/ | briggs@ninthwonder.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Yeah, it's kind of a gamble - some Just Work, others don't even True. So we should probably have an ALL that contains everything and leave in GENERIC what's known working? have fun Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBRuRmWspnzkX8Yg2nAQLrzgf/QuWsDeAVA8cwmlW30xccgzG5k/gpsE/N 0KB5IOq2w6Xdc3NheuawmzEEJyWvTMqyYiodiAPjUvza1dfHEbJEdvBUe0WuU+b9 QFG2lhtXNDhFuPoNLlIu6PwbGykAAuhBBVCLMh3YwNa3gSm/vv0QlKfGRGZCFufk cS6Er2kybr5UK6YfNjONzg0mXWR/Kr2GFIsh3vn4a9YHYbUuiYC3Mn7OESWBf6uY 0xaZbJfcZkKFoYQkOYL1msbJKU2+2DPWjpAtj5zJP36pjgVckbuLb2+QWLt1JR0Z yspLRmjWeHFRJ0WN9bm5xifzxQGOo3UNextLRGpYPVnpCL6Yugd4JQ== =HwlE -----END PGP SIGNATURE-----
> None of the problems that I saw would be caught by a compile--only by > trying to use the hardware. I don't have a real problem with including > devices in a compile, but making the leap to "supported" or "expected > to run" would be unconscionable. True. So we should probably have an ALL that contains everything and leave in GENERIC what's known working? perhaps we can put "no foo at bar" in GENERIC for devices not yet known to work, and leave ALL with everything? .mrg.
I think this would be an even bigger reason to *include* them by default. This is very likely to increase the exposure and a bug report from someone that tried to run a driver and failed is better than the I would make a chart like the platform features (e.g. TC support). That is better on www then in the actual source code though. Joerg
i think i like this.. i like pooka's config -f idea. one problem i'm aware of is that many "MI" drivers are not truly MI and don't compile everywhere. eg, there are several network devices that are not available on sparc64 due to this. see sparc64/conf/GENERIC for details... .mrg.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Why didn't anyone fox that? Another case of right hardware not in right hands? have fun Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBRuMWaMpnzkX8Yg2nAQLVCAf+KQwgN1RCaVyw05F3veoasUVC2+B+sJlP 8btDixslD+fyGKofEWCp+0JMPMpvZjRF1bqCPEp/zMNDnIHh32Ag6+fVpn9zZrjZ TnzIyaIH7FqQst0ZwB1LaQHNlquC6m8EBHgBaWnKz8nO6wz+tkHROYCAAa1om+bL 2Ri2/YA9AN+f0mSF8+WZGVMB+QgnBqkdFgm+k6/p7wVKxudb75YMOstwiQpj8BOP 6Po+okGogerhprhO4f/L5BLJk+wcC3NkfSsKwq6O8S1Xxy5GJLpDb2qXA7TEo/Sw F0K+rdGDcltNZR5JRhemf0qKNRbkyUdMsBc1kDvNQXZirwIUwZwyew== =vrXQ -----END PGP SIGNATURE-----
> i think i like this.. i like pooka's config -f idea. > > one problem i'm aware of is that many "MI" drivers are not truly > MI and don't compile everywhere. eg, there are several network > devices that are not available on sparc64 due to this. see > sparc64/conf/GENERIC for details... Why didn't anyone fox that? Another case of right hardware not in right hands? basically.. in some cases, these are 10mbit ethernet cards or other poor 100mbit cards that don't compare to onboard at all, so the desire to care is very, very low :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Eh, I guess few would bother with an ne if there's a hme onboard ;) ( although ne at pci works at least on macppc so chances are pretty good it would work on sparc(64) as well ) have fun Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBRuMuT8pnzkX8Yg2nAQLWqgf9FdygmUAYIfLK1LKDs7DnrqYmw3CIsoBq diis7WBeNqw8VsE75ODXTT2b3Qf2eBZnpI2giOt1y9NkWzzjP5yLT8rHPb7vUH0q t0cve1QexRLl8nKe+7oKxjxYie3mW7BYi4ng8r9VHlkWL9mXHxvJrbF2Q2mSIsZg EppI8Qg5SHEUcc5X1G7KmLAkFE8hOfiyQWfMolctt6RriAEluUwuvGua/DVy0cAW /teQ+HnJ2SNSKe04a98Qr+/LNgNa6sHzFLcCFriTMV0lbHN7h8vJlzcQlga/tPF2 4rS9fO1K7yl6uFeCe2UZfXrJCiCVVJjoDILCWrG/ABmBJO7T+CET6g== =GAiA -----END PGP SIGNATURE-----
Eh, I guess few would bother with an ne if there's a hme onboard ;) ( although ne at pci works at least on macppc so chances are pretty good it would work on sparc(64) as well ) doesn't macppc have vtophys()? any driver using it won't work on sparc64. .mrg.
In dev/pci only bktr and oboe match that (with possible conditional code in de(4)). Joerg
Yes, I like this too... And to aid in building slimmed down config files, is there a "dmesg to config" script or program that can be wrong which looks at the kernel and works out which drivers are where and how the config file should look like? Darren
On Sun, 09 Sep 2007 19:41:43 -0700 pkgsrc/adjustkernel/DESCR --Steve Bellovin, http://www.cs.columbia.edu/~smb
I like the general idea, but I don't think it should be fixed by
maintaining yet another file. What you (seem to) really want is a
config(1) extension like:
# Fabricate wildcarded instance for any driver capable of attaching
# at "pci" attribute (using the proper attachment of course).
any pci
This should be fairly easy to implement and the 'no foo' feature gives
you a way to avoid borken drivers. Rationale for this approach is that
config(1) already knows about all drivers/attachments/attributes via
files.* lists (included normally via std.${arch}), so we might just as
well make use of that instead of doing the work manually.
What do you think?
-- Jachym
Firstly, this will only work with direct config buses. Secondly, it just makes it harder to understand what's going on. Adding more and more magic in config(5) will not help maintaining anything in the long run, at least not for kernels meant to be used (and possibly changed) by users. --=20 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org "You could have made it, spitting out benchmarks Owe it to yourself not to fail" Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
I would prefer to have well working support for device driver modules which get loaded on demand. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Seconded, and I think that spending time enhancing 'config' further is a waste of time. What are the problems with LKMs? I can think of some: - LKMs need to be compiled to match the kernel, MULTIPROCESSOR and so on. I have been working on this, and expect that it won't be a problem any more in a couple of months time. - LKMs depend on kernel data structures which change often. Again I've been working on this one, e.g. the recent callout changes although there's a lot of work to be done on this. - The kernel needs to be able to load modules itself, and that means an in-kernel linker. - The autoconfiguration framework isn't suited to loading device drivers. The drivers have to do some quite odd things in order to find a device to drive and get attached. - Mechanisms to prevent in-use modules from being unloaded are missing. For example, a syscall module can be unloaded while its syscall is in use. What other problems are there? On a slight tangent I also think that many of the configuration files have become abominable because we have been abusing the config system. That leads to code that's hard to maintain and a system that's more difficult to use. I'm guilty of that as much as anyone else. Broadly speaking the options I can see fit into one or more of the following categories, with some examples I took from the i386 configs: valid: - describes an optional subsystem or behaviour (DIAGNOSTIC) - should force a module to be compiled into the kernel (COMPAT_LINUX) invalid: - microptimizaton with no benefit (I386_CPU) - saves a few bytes (WSDISPLAY_COMPAT_PCVT) - forces user to handle a condition that the code should (TIMER_FREQ) - should be a runtime tunable (SHMMAXPGS) - has runtime tunable, remains for sentimental reasons (GATEWAY) - should be a device driver (VIA_PADLOCK) - too fine grained (COMPAT_09, COMPAT_10, COMPAT_11, ...) I know that it takes time and effort to change things and undoubtedly I have offended someone with the ...
On Tue, 11 Sep 2007 14:35:40 +0100 Security -- it's much easier to plant a rootkit in a running system with an LKM. That said, loading drivers at boot-time -- as FreeBSD can do -- wouldn't have that risk. --Steve Bellovin, http://www.cs.columbia.edu/~smb
The path to making this better is to have more formal API specifications for what the kernel exports in terms of functionality, etc. In some places we may not have APIs that we need to use but do not qualify for this yet. If you have a list of troublesome structures, functions, etc, it may be worth posting that so others can look at it and potentially help you reduce its size. How many of the "invalid uses of config" have you created PRs for? Darren
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regards - ----------------------------------------- Adam Hamsik jabber: haad@jabber.org icq: 249727910 Proud NetBSD user. We program to have fun. Even when we program for money, we want to have fun as well. ~ Yukihiro Matsumoto -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG5vSmlIxPgX3Go0MRApbdAJ9Zo50kk0BhatOpja7BTRjksWZPjQCgxQZo 1pVLnhfZ2TBk1uI2n1My/HY= =6QXt -----END PGP SIGNATURE-----
Sorry, but that is 100% orthogonal. Well, not 100% -- if you don't know that the drivers build in the kernel, you can't expect them to work as LKMs. That doesn't mean I wouldn't like to see improvements in that area. Joerg
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth |
| Linux Kernel Mailing List | ixbge: remove TX lock and redo TX accounting. |
| Linux Kernel Mailing List | ixgbe: fix several counter register errata |
| Linux Kernel Mailing List | b43: fix build with CONFIG_SSB_PCIHOST=n |