Messages in this thread | | | Date | Thu, 11 Sep 1997 16:56:22 -0400 (EDT) | From | James Mastros <> | Subject | Re: CONFIG_SMP patch available for 2.1.54 |
| |
(Note to linux-kernel: the mail this is in reply to wasn't cc-ed to linux-kernel; I included it in full here.)
On Thu, 11 Sep 1997, David Woodhouse wrote: > root@jennifer-unix.dyn.ml.org said: > > Then you must not really need it; > Curiously enough, that's very similar to what my father said when I asked him > to lend me some more money last month :) > > > 1) It would require a complete rewrite of the dependincy generation > > (probably with a modified "make" command). (Admittedly, make dep > > seems rather screwey to me, but that's probably just me). > We're throwing around ideas that won't need that. Like separating each > CONFIG_xxxx option into its own file. Not so nice either, but there _has_ to > be something that'll do it OK. > > > 2) You can't #undef somthing to a value. > No, I didn't think you could; I thought we'd have to do something different. > But I checked it, and gcc didn't even whinge about it. I checked nested > functions in gcc the other day, just to check that I was right before > telling "someone you can't do that in C," and was amazed to find that it lets > you do it.
You can do that (nested functions) in gcc, but not in C (ANSI or K&R). Unfortunately, in theory, the kernel shouldn't rely on GNU specific functionality (as opposed to simply being implemented in terms of it). The differece is slight. If you can trivilaly re-write it without the extensions, then it's just implemented in, otherwise it relies on the GNU extention. (Morver, I think this is undocumented behivior.) In any case, there is no way to get this value back with a pre-processor macro (not that it matters in this case.
> > 3) The value of many config options is already defined (IRQs...) > Erm... some things like MAX_SCSI_LUNS, yes. Perhaps if we take this option > the timestamp should in /* ... */ People have been giving better ideas > though, so I don't think it'll be done like that. Agreed.
> > Perhaps we could comprimise with having include/linux/config/ > > config_a.h with CONFIG_A* in it; include/linux/config/config_b.h with > > CONFIG_B*, etc. Note that if anything like this is going to happen, > > we need mv-if-changed (really quite trivial). Mv-if-changed is a > > good thing anyway. > > I'd prefer to have the things grouped together by functionality rather than > lexicographically (sp?), but yes, that's a fine plan.
Ahh, but the only functionality information of this sort is what Config.in defines the option. It seems to me that we would want to have smaller catagories; there are only 13 Config.in files. And I don't see any non- lexagraphic way of having small groupings of config options automaticly. (We could re-write the config scripts to define the file explicitly for each option, but that seems ugly to me). We could replace the _ with a / and then strip off the last level, but that creates one oversized file and a bunch of small ones. In any case, functional groups are often also lexagraphical groups, since they often have a shared prefix.
> When I get back to College next month, I won't be getting paid any more, so > will be able to work on what I like. I'll go play with a few things, and see > what performs best. Hell, I don't get paid now! <G>
> -- > David Woodhouse, CB3 9AN http://dwmw2.robinson.cam.ac.uk/ > dwmw2@cam.ac.uk Tel: 0976 658355 > D.W.Woodhouse@nortel.co.uk Tel: 01279 402332
-=- James Mastros
--- I can now be reached again at abszero@epix.net or root@jennifer-unix.dyn.ml.org. "Shooting as [a] communications method is obsolete even here in Bosnia, so I'll skip over it." -=- Dragisha Durich
| |