Re: [kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Randy.Dunlap wrote: stick with TCL/TK, like xconfig currently uses ? Too ugly. I actually think QT is a fine choice, I just suspect that it's going to cause political issues. My favourite approach by far is to actually not ship anything graphical with the kernel at all, and just hope that the config language syntax is stable enough that different groups can do their own as external packages. The kernel would ship with just the text-based reference implementation (if even that - we could just have a few supporting packages). The only thing I personally really care about is the Config language, since that _has_ to ship with the kernel. Linus PS. And while we're talking about the language - I'd actually prefer the syntax depends on or requires instead of depends, to make it grammatically more correct. And those help-texts should be separated some way so that they don't blend in quite as badly with the command section. Maybe something really syntactic like just replacing the help keyword with a ---help--- keyword. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Sam Ravnborg wrote: Another suggestion about naming: Take for example drivers/net: cat Config.* | wc = 2149 lines A bit a structure could be needed here. Net.conf = Name equals directory with upper-case first letter - Cover the whole directory, and either implicit or explicit include other .conf files in that directory 3c5xx.conf = All the configuration for the 3c5xxx chipset drivers rrunner.conf = All configuration for rrunner driver Good point. Splitting up the big Config.in files is a good idea anyway, and it becomes even more important when the Config.help information was included in the file. However, I disagree with the naming - I'd rather have one common name for the main directory entry than have magic rules like basename of the directory capitalized. I don't want to have to search for it. I also think I'd perfer to have them all start with the same thing, so that (again) it's clear when a directory has multiple configuration files. So instead: how about just Config for the main per-directory configuration file, with sub-config's being Config.3c5xx and Config.rrunner. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Sam Ravnborg wrote: ls rrunner* should show me not only the implementation [.c + .h] but also the configuration. I agree with you, but only if we _always_ have one config file per driver. Which is not necessarily the wrong thing to do. But as long as most drivers are in grouped config files, they should be things like Config.3com etc. Looking at existing big config files (video, networking), they do _not_ group according to driver, but according to other criteria (ie PCI card, 100/1000 Mbit, 3com, Sparc-specific etc). Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Roman Zippel wrote: Linus, do you have any interest in merging it in the near future? If not, what's missing? I'm not super-excited about this, partly because of the brouhaha last time around on this issue. This has reasonably distributed config files, and puts the help with the config entry where it belongs. Good. It also makes do with just standard unix tools, which is going to avoid one particular rat-hole, and which makes me at least understand the code. Also good. But the fact that xconfig depends on QT is going to make some people hate it. And I haven't actually heard much _about_ this all, because (apparently as usual), all the discussion is held in a small world of its own. In other words, I really think this needs to pass the linux-kernel stink test. Will Al Viro rip your throat out? Will it generate more positive feedback than death threats? Some things made me go eww (but on the whole details): - I'd prefer the Config.in name, since this has nothing to do with building, and everything to do with configuration. - I assume that the scripts are generated from the current Config.in and Config.help files, and it would make me slightly happier to see the diff as a automatic script + diff to fix it up, just for doc purposes. - that lkc name has got to go. Three-letter acronyms are not good. Of course it's linux kernel, the whole tree it sits in is linux kernel. Call it config or something obvious, please.. - Quick testing showed that the first thing I tried didn't work: giving a ? as answer to the first question did _not_ result in help. make oldconfig seemed to do the right thing, though. Let the flames begin. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Get rid of shell based Config.in parsers?
On Wed, 14 Aug 2002, Sam Ravnborg wrote: Where comes the requirement that we shall keep the existing shell based config parsers? I use them exclusively. It is far and away the most convenient parsing - just to do make oldconfig (possibly by making changes by hand to the .config file first). As far as I'm personally concerned, the shell parsers are the _only_ parser that really matter. So if you want to replace them with something else, that something else had better be pretty much perfect and not take all that long to build. Linus --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Legacy Fishtank wrote: A per-driver metadata file is IMHO clearly the preferred solution. Note that it doesn't need to be per-driver: there are good reasons to have combined files too. For example, things like architecture config could all be in one file, along with similar drivers (ie 3com network devices, whatever). Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Sat, 29 Dec 2001, Keith Owens wrote: Yes, some of the problems with mkdep can be fixed in the current design but there is one problem that is inherently unfixable. make dep is a manual process so it relies on users knowing when they have to rerun make dep AND THEY DON'T DO IT! Don't be silly. Make the dependency file itself depend on all the files it describes, and add a makefile rule to re-generate it. Poof, problem gone. Dependencies _do_ change when your .config changes, Only if you do them wrong. Look at mkdep.c - it statically determines the complete list of header files that _can_ be included, and does not care at all about what config options there are. that are included varies. gcc -MD gets this exactly right, gcc knows which files it read. Bzzt, it knows the subset of files to read, nothing more. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
[ Btw, Jeff, any reason why you changed your name to Legacy Fishtank? It took a few mails before I noticed that it also said garzik in the fine print;] One thing that this big flame-war has brought up is that different people like different things. There may be a simpler solution to this: have the core dependency files generated from some other file format. My pet peeve is centralized knowledge. I absolutely detested the first versions of cml2 for having a single config file, and quite frankly I don't think Eric has even _yet_ separated things out enough - why does the main rules.cml file have architecture-specific info, for example? That's a big step backwards as far as I'm concerned - we didn't use to have those stupid global files, and each architecture could do it's own config rules. Eric never got the point that to me, modularity is _the_ most important thing for maintenance. Something I also asked for the config system at least a year ago was to have Configure.help split up. Never happened. It's still one large ugly file. Driver or architecture maintainers still can't just change _their_ small fragment, they have to touch a global file that they don't own. So if somebody really wants to help this, make scripts that generate config files AND Configure.help files from a distributed set. And once you do that, you could even imagine creating the old-style config files (without the automatic checking and losing some information) from the information. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Alan Cox wrote:
So if somebody really wants to help this, make scripts that generate
config files AND Configure.help files from a distributed set. And once you
do that, you could even imagine creating the old-style config files
Something like:
find $TOPDIR -name *.cf -exec cat {} \; Configure.help
For old tools..
or changing the tools to look for
Documentation/Configure/CONFIG_SMALL_BANANA
small banana? Freud would go wild.
But no. I don't want it under the Documentation directory: I'd much rather
have them _together_ with the config file.
So the config file format could be something that includes the docs, and
you could do something like
find . -name '*.cf' -exec grep '^+' {} \; Configure.help
for old tools, and nw tools would just automatically get the docs from the
same place they get the config info.
And there would _never_ be more than a few entries per config file: you
can imagine having a separate config file for PCI 100Mbps ethernet drivers
and one for ISA drivers.
The current Configure.help is 25k _lines_, and over a megabyte in size. I
would never consider that good taste in programming, why should I consider
it good in documentation?
Linus
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Eric S. Raymond wrote: I'm not certain what you're objecting to, and I want to understand it. There are rules that use architecture symbols to suppress things like bus types. I presume that's not a problem for you, but tell me if it is. It _is_ a problem for me, because I want to do diffstat on a patch from a PPC maintainer, and if I see anything non-PPC, loud ringing noises go off in my head. I want that diffstat to say _only_ arch/ppc/... include/asm-ppc/... and nothing else. That way I know that I don't have to worry. In contrast, if it starts talking about Documentation/Configure.help and the main config file, I start worrying. For example, that MATHEMU thing is just ugly. It was perfectly fine in the per-architecture version, now it suddenly has magic dependencies just because different architectures call it different things, and different architectures have different rules on when it's needed. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Legacy Fishtank wrote: I think one thing to note is that dependencies is that if you are smart about it, dependencies -really- do not even change when your .config changes. Absolutely. I detest gcc -MD, exactly because it doesn't get this part right. mkdep.c gets this _right_. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Eric S. Raymond wrote: Legacy Fishtank [EMAIL PROTECTED]: Note I am specifically NOT talking about MAINTAINERS and CREDITS. -PLEASE- don't obscure my point by mentioning them. It's the same problem, Jeff. Same solution, too. It's not. We already have pre-file credits information - people can put stuff in there for their own (C) messages etc. The MAINTAINERS file is a much higher-level thing which is there to be human-readable. Note that I do _not_ want to mess up source files with magic comments. I absolutely detest those. They only detract from the real job of coding, and do not make anybody happier. We have a hierarchical filesystem. Most drivers already have driver.c driver.h (in fact _very_ few drivers are single-file) and some have a subdirectory of their own. So why not just have driver.conf and be done with it. No point in messing up the C file with stuff that doesn't add any information to either the programmer _or_ the compiler. Then you can make the config file _truly_ readable, and make the format something like define tristate CONFIG_SCSI_AIC7XXX: Adaptec AIC7xxx support This driver supports all of Adaptec's PCI based SCSI controllers (not the hardware RAID controllers though) as well as the aic7770 based EISA and VLB SCSI controllers (the 274x and 284x series). This is an Adaptec sponsored driver written by Justin Gibbs. It is intended to replace the previous aic7xxx driver maintained by Doug Ledford since Doug is no longer maintaining that driver. depends on CONFIG_SCSI depends on CONFIG_PCI depends on ... define integer CONFIG_AIC7XXX_CMDS_PER_DEVICE: Maximum number of TCQ commands per device depends on CONFIG_SCSI_AIC7XXX default value 253 define integer CONFIG_AIC7XXX_RESET_DELAY_MS: Initial bus reset delay in milli-seconds depends on CONFIG_SCSI_AIC7XXX default value 15000 and it's readable and probably trivially parseable into both the existing format (ie some find . -name '*.conf' plus sed-scripts) and into cml2 or whatever. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Alan Cox wrote: It would certainly fit nicely with the existing metadata. We already rip out code comments via kernel-doc, and extending it to rip out - Help text - Web site ... No no no. The comments can at least be helpful to programmers, whether ripped out or not. Extra stuff is not helpful to anybody, and is just really irritating. I personally despise source trees that start out with one page of copyright statement crap, it just detracts from the real _point_ of the .c file, which is to contain C code. Making it a comment requirement is - stupid: we have a filesystem, guys - slow: we don't need to parse every C file we encounter when we can just open another file based on filename - nonsensical: many config options are _not_ limited to one C file - hard to parse and read: why limit ourself to C comments, when just keeping the thing logically separated means that we don't have to. Having per-function comment blocks, in contrast, makes sense to have inline: - you read the comment when you read the function - you might even update the comment when you update the function - you have a reasonable 1:1 relationship. _None_ of those are sensible for config file entries. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: your mail
On Thu, 27 Dec 2001, Andre Hedrick wrote: Lots of luck ... please pass your crack pipe arounds so the rest of us idiots can see your vision or lack of ... Heh. I think I must have passed it on to you long ago, and you never gave it back, you sneaky bastard ;) The vision, btw, is to get the request layer in good enough shape that we can dispense with the mid-layer approaches of SCSI/IDE, and block devices turn into _just_ device drivers. For example, ide-scsi is heading for that big scrap-yard in the sky: it's not the SCSI layer that handles special ioctl requests any more, because the upper layers are going to be flexible enough that you can just pass the requests down the regular pipe. (Right now you can see this in block_ioctl.c - while only a few of the ioctl's have been converted, you get the idea. I'm actually surprised that nobody seems to have commented on that part). The final end result of this (I sincerely hope) is that we can get rid of some of the couplings that we've had in the block layer. ide-scsi is just the most obvious strange coupling - things like sg.c in general are rather horrible. There's very little _SCSI_ in sg.c - it's really about sending commands down to the block devices. The reason I want to get rid of the couplings is that they end up being big anchors holding down development: you can create a clean driver that isn't dependent on the SCSI layer overheads (and people do, for things like DAC etc), but when you do that you lose _all_ of the support infrastructure, not just the bloat. Which is sad. (And which is why things like ide-scsi exist - IDE didn't really want to be a SCSI driver, but people _did_ want to be able to use some of the generic support routines that the SCSI layer offers. You couldn't just cherry-pick the parts you wanted). The other part of the bio rewrite has been to get rid of another coupling: the coupling between struct buffer_head (which is used for a limited kind of memory management by a number of filesystems) and the act of actually just doing IO. I used to think that we could just relegate struct buffer_head to _be_ the IO entity, but it turns out to be much easier to just split off the IO part, which is why you now have a separate bio structure for the block IO part, and the buffer_head stuff uses that to get the work done. Andre, I know that you're worried about the low-level drivers, but: - I've long since noticed that we cannot communicate, which is why Jens is the block level driver person. You'll have to live with it. - I personally don't think you _can_ make a good driver without having reasonable interfaces, and we didn't have them. For example, the network drivers have improved a lot and do not have _nearly_ the amount of problems block drivers have. That's obviously partly just because it is a simpler problem, but because it was simpler it was also possible to change them. The infrastructure changes in the networking during 2.3.x really did help drivers. And note that the Jens and communication part is important. If you have patches, please talk to Jens, tell him what the issues, are, and I know I can communicate with him. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: your mail
On Fri, 7 Dec 2001, Keith Owens wrote: Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. We're getting the block IO layer in shape first, the time has not come for _anything_ else before that. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
