Date: Sun, 20 Dec 1998 16:45:18 -0800 From: Mike Smith <mike@smith.net.au> To: Eivind Eklund <eivind@FreeBSD.ORG> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk bsd.kern.mk src/sys/alpha/conf Makefile.alpha Message-ID: <199812210045.QAA47965@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 21 Dec 1998 01:38:52 %2B0100." <19981221013852.B10676@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I've moved this to -arch; while it's generally relevant, it's not really suited for discussion on the CVS lists... > > > bus/ # Bus-specific code > > > eisa/ > > > dev/ # Devices for this bus > > > <types> # Type specifiers for drivers > > > > This isn't even learning from our current mistakes. (cf. everything in > > sys/pci that frontends for stuff in sys/i386/isa) > > This was intended for the front end stuff and drivers that are by > nature tied to a specific bus. Usually, the parts here should just > set up any magic bus-spaces or similar, and call things in /dev/. Ok; I think the 'dev' entry there threw us off. > > > This is just a very quick attempt at a hierarchially based layout; I'm > > > sure there are lots of possible improvements. > > > > The current drive is to tear the kernel into modules wherever possible; > > ultimately the kernel core will remain, and everything else will be > > modules. So: > > > > boot as current /sys/boot > > ... > > compile > > i386 not convinced of the requirement for > > ... arch subdirs here. > > alpha > > ... > > modules > > ... > > Not convinced of the requirement for sys/compile. For a fully > functional build system, architecture is only one of the relevant > axes, the others being the options used. Sure; I tend to think that the only meaningful, manageable uniqifer is the kernel ident anyway, so just "a scratch area" would suit me. > Apart from that, I have no problem with your suggested layout except > that it lack detail in a number of areas. I figured you'd already gone into more than enough detail; I only wanted to make the point that if we're cutting things up, we should look more than a few inches ahead. > > > > (Any ideas on how to get enough people to agree on change?) > > > > > > Not a clue. > > > > Almost impossible, unless you can sell them on losing the CVS history. > > We'd use repository copies, of course. That doesn't make it particularly easy to watch changes across the repo copy... > If we are going to do a rearrangement, we should do it just before we > create a new release tag. (I was thinking that with 3.0 released > right now was the worst time possible, and was going to attempt to > squash the discussion, but it really is the best - RELENG_2_2 is on > end-of-life, and RELENG_3_0 isn't put down yet). It's certainly less painful to do it at a pinch point, where there's only one branch to bend. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812210045.QAA47965>