From owner-freebsd-arch Sun Dec 20 16:50:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA14707 for freebsd-arch-outgoing; Sun, 20 Dec 1998 16:50:25 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA14701 for ; Sun, 20 Dec 1998 16:50:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA17049 for ; Mon, 21 Dec 1998 01:50:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA11302 for freebsd-arch@freebsd.org; Mon, 21 Dec 1998 01:50:21 +0100 (MET) Received: from dingo.cdrom.com (castles336.castles.com [208.214.167.36]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA14332; Sun, 20 Dec 1998 16:47:33 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA47965; Sun, 20 Dec 1998 16:45:18 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812210045.QAA47965@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Eivind Eklund cc: freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk bsd.kern.mk src/sys/alpha/conf Makefile.alpha In-reply-to: Your message of "Mon, 21 Dec 1998 01:38:52 +0100." <19981221013852.B10676@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Dec 1998 16:45:18 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > > # 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