Re: config(5) break down

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Fri, Mar 26, 2010 at 05:39:03PM +0700, Robert Elz wrote:
>     Date:        Fri, 26 Mar 2010 14:52:09 +0900
>     From:        Masao Uebayashi <uebayasi%gmail.com@localhost>
>     Message-ID:  
> <70f62c5e1003252252h6e5ba506xfafceb76f854b957%mail.gmail.com@localhost>
> 
>   | You need to include dependency.  You don't need to care the order of
>   | include lines.  This is pretty much same as C headers including its
>   | dependency vs. not include in *.h but managing the order in *.c.
> 
> But C include files are a disaster - a huge mess inherited from history.
> No-one sane would deliberately design that as a solution for anything.
> As a user of the things I'd much rather all that just happened automatically,
> when I use fopen() if the compiler needs stdio.h, it should just go and
> get stdio.h - it's absurd to make me explicitly say I need it.
> 
> For C, because of the nature of the world 30+ years ago, and development
> since, there's nothing we can do about it.   But copying that as if it was
> a great system would be absurd.

We all know implications and limitations of "include" conventions.

>   | Same as pkgsrc "buildlink3.mk" including its dependency too.
> 
> No, those are totally different - those are different files because
> they're managed separately, as a part of each package - the maintainer
> of graphics/jpeg looks after jpeg/builink3.mk and makes it does whatever
> is necessary to correctly link whatever -ljpeg required.  Those are
> separate files, not because separate files is a good thing, but because
> the management of anything different would be a nightmare.
> 
> If your reason for lots of little conf files was because there are lots of
> little independent projects, each producing and looking after their own
> little piece of the puzzle, that would be something that might reach
> agreement (if it were correct).
> 
> But the reason seems to just be this dependency ordering thing - which it
> looks like you're planning on solving it the .h file way (with each file
> including anything it needs, then added protection against including anything
> more than once, and ... which is all just a huge mess).
> 
> That's not the way to fix this problem.  If it has become serious enough that
> doing it manually is no longer sensible, then just fix config to remove the
> ordering rule - I don't think there's any good reason for it (and you 
> certainly
> are not proposing making it stronger).   Making config do a two pass parse of
> the config file(s) would be an afternoon's work - it was never done that way
> because manual ordering started out being so simple to do, that the 
> afternoon's
> work was never justified.   Then, as each new entry was added, manually 
> ordering that new entry was always less than that afternoon's work.  Almost
> certainly the sum of all of that effort is (now) greater than the effort it
> would have taken to fix config, but no-one has ever really fallen against
> it hard enough that they could justify spending the afternoon to fix it.
> 
> Maybe that's changed now - certainly I suspect that there's been more time
> spent on this discussion than it would take to have just fixed config in the
> first place.
> 
>   | Having a
>   | single *.conf per module is natural.  As natural as userland commands
>   | and libraries have a single Makefile for each.
> 
> This one is a different argument (and as I remember this is more where
> you started, before you got onto that ordering nonsense), this relates more
> to management, and is much more reasonable.

This is almost same thing as modularity.

> However, since I'm a believer in the single module kernel, that also makes
> me a believer in the single files.conf file - and for people like me,
> following this line of reasoning, you'd agree right?  (Regardless of whether
> or not you agree with the single module approach).

Are you a believer in the single netbsd.c, yes?

Complaining the number of possible split config files is as pointless as
complaining the number of *.c files in src/sys.  The reason why we'll end up
with thousands (not millions) of *.conf is that the netbsd kernel is composed
of thousands of components.

If your real complainment is about putting build procedure / module dependency
in a separate file, you should consider to propose merging bin/*/Makefile
into bin/*/*.c.

My long term goal is to make ~everything in src/sys modules, without digging
sys/modules/*.  Without scattering build a single procedure of ehci(4) across
sys/conf/files and sys/dev/usb.

> I'm pretty sure he understands the existing syntax.  I am pretty sure that
> I understand the existing syntax as well.   The syntax of what is in the
> file(s) is pretty much an orthagonal issue - I certainly agree that the
> syntax could be improved, but I don't see that having almost any bearing
> upon the multiple files issue - it doesn't need to change to allow a 2 pass
> parser to remove any ordering relationship on the config file lines,
> and it can change, whether we have one config file (as it once was), a dozen
> or whatever it is now, or a hundred or more (your proposal).
> 
> When mrg said he wanted to cry, or laugh, at your message, I suspect it
> was because if there had been a zillion little files, the weekend you spent
> would probably have been at least a week....

Obviously you haven't wasted enough time to learn config(5).

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635