Date: Fri, 16 Apr 1999 17:17:39 +0900 From: UCHIYAMA Yasushi <uch@nop.or.jp> To: peter@netplex.com.au Cc: rwhitesel@nbase-xyplex.com, dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: newconfig/new-bus Message-ID: <19990416171739K.uch@nop.or.jp> In-Reply-To: Your message of "Wed, 14 Apr 1999 03:53:16 %2B0800" <19990413195319.16D6A1F4F@spinner.netplex.com.au> References: <19990413195319.16D6A1F4F@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
| shouldn't be too hard though, but even then there are seriously non-trivial | differences in the tty, block/character devices, VM, networking, etc. Even | if the config interface was compatable it wouldn't ever be a 'drop in' | option, even with 'newconfig'. In strongly system-dependent part, even if newconfig, it is required many source change. But *BSD difference is smaller than other OSes. Except for static configuration and module dependency resolvation, I feel new-bus and newconfig have the same possibility. So new-bus seems to `re-invent the wheel'. Why not improve 4.4BSD newconfig? Except for FreeBSD, almost all the drivers are newconfig. (FreeBSD's oldconfig should die) What is merit of new-bus? Identity? current newconfig code don't support dynamic configuration. but this is not newconfig potential. Furuta and I intend to code it. --- UCHIYAMA Yasushi uch@nop.or.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990416171739K.uch>