tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: config(5) break down
On Fri, Mar 26, 2010 at 1:55 PM, matthew green <mrg%eterna.com.au@localhost>
wrote:
>
> To manage dependency nicely.
>
> When a module A dpend on B, you write "define A: B", where B has to be
> already "define"'ed in the current syntax. We're managing such
> ordering "by hand" in sys/conf/files. By splitting files & use
> "include", we don't need to manage such a mess by hand. David Holland
> already understood this:
>
> http://mail-index.netbsd.org/tech-kern/2010/03/11/msg007633.html
>
> So we have already agreed that split has "some" benefit. The point
> is, my split+include way doesn't need any syntax change.
>
> the above mail doesn't agree with splitting files* for every
> device. it agrees that some better ideas might be useful.
>
> i like your ideas about using "define" better, and being more
> clear about dependancies, but why do you need so many files?
> (given the above url, i like the "(2)" option for the split.)
>
> i have no idea how splitting them makes the ordering no longer
> "by hand". the ordering is still explicitly done by hand, it
> is just done in a bunch of files now, using more lines than
> would previously be required. eg, instead of all the drivers
> in files.pci being how they are today, they each get to have
> to "include" all the PCI definitions, and other ones. each
> driver / module file will have a large list of "include"s,
> all managed by hand. seems ugly and inefficient to me.
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. Same
as pkgsrc "buildlink3.mk" including its dependency too. Having a
single *.conf per module is natural. As natural as userland commands
and libraries have a single Makefile for each.
Eventually we'd run config(1) and build modules for each *.conf. For
example, if you want to build if_bge.kmod, what you need are sources
(if_bge.c, if_bge*.h) and the split config files (if_bge.conf and its
dependency). Because if_bge.kmod doesn't need to know everything
about kernel build; it needs to know itself and its dependency to
generate the stub (relevant part of ioconf.c).
> I'm not saying changing syntax is bad. My complaint is that David
> Holland is suggesting things without understanding the existing
> syntax. I spent a whole weekend to read sys/conf/files, ioconf.c, and
> module stubs in sys/dev/usb/uaudio.c. I wasted a whole weekend. I've
> been wasting more time to convince David Holland who has never
> bothered to understand the existing syntax.
>
> i read this and i look at the devfs thread and i am not sure
> if i want to laugh or cry.
I've spent >1 month to figure out the bus_space_physload(9) API.
Which means I've wasted >10K USD to design that single function. Feel
free to laugh at me.
Masao
Home |
Main Index |
Thread Index |
Old Index