lkml.org 
[lkml]   [1997]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:1.572 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site