Date: Mon, 08 Jun 1998 21:14:10 -0700 From: Mike Smith <mike@smith.net.au> To: Jun-ichiro Itoh <itojun@itojun.org> Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, tech-jp@jp.freebsd.org Subject: Re: new config Message-ID: <199806090414.VAA00467@antipodes.cdrom.com> In-Reply-To: Your message of "Tue, 09 Jun 1998 13:21:42 %2B0900." <9929.897366102@cardamom.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hello, this is Jun-ichiro Itoh. > What is the plan for "config" program? Specifically, when will > FreeBSD move to "new config" which is used by NetBSD or BSDI? Whilst I can't speak for core, I'm reasonably familiar with the work in this area. I don't believe that there are any plans at all to adopt the "new config", and certainly nobody with any code aimed in this direction. Newconfig imposes very strict hierarchical structure on the system, and whilst well-geared towards a static configuration, is much less well suited to dynamic operation (my evaluation only). Bearing in mind that it has been at least a year since I had anything to do with newconfig, I'd be interested in more clarification. Can you clarify when you talk about "new config", do you specifically mean the "new config" tool, or an improved bus/resource/driver model? > On June 3rd, there was FreeBSD BOF at Interop98 Tokyo, and > it became very clear that many project has been stucked due to the > fact FreeBSD is using old config. > For example (this is basically summary of discussion): > - With old config, the order of probe/attach is defined sorely by > the type of bus, say, pci_configure() then isa_configure(). > There are devices that are not happy with this method, such as > cardbus controller. This is very similar to newconfig, where discovery is performed in a tree-recursive fashion, no? > - PAO/laptop support people would like to have separate bus type > for pccard and cardbus. Cardbus people feels that they cannot make > progress any more without bus separation. Current probe/attach > mechanism used for laptop support is not clean enough, and very hard > to understand. Also, this is affected by order-of-probe problem > (the previous item). > (pccard attach routine fills intr/port information and calls isa > attach routines, basically) There is nothing stopping the CardBus people having a new bus type for CardBus; here I can see how the new config style of resource control by parent indirection would help. > - Cannot pass "flags" field to pci devices. Here we run up against one of the fundamental problems that the entire BSD config structure, new and old, possess - you can't pass parameters to something that you haven't already defined. If I have three instances of some hardware that uses the 'foo' driver, and I want to pass a parameter to one of the three, the parameter has to be associated with a structure that will in turn be associated with this hardware, and the structure has to be defined in advance. This makes truly dynamic handling of hardware very difficult. It is one of the reasons that nobody has become terribly enthused about "new config" - it's not that much better than "old config". > - isapnp/pci should have a separate bustype from isa, of course. Not at all. The issue here is one of functional separation between the "probe" and "attach" components. Probes are inherently bus specific, but attaches are not, provided that the correct bus abstraction is provided to the attach. A major problem faced with migrating our current (ISA) driver base towards this model is that many drivers perform parts of their hardware setup in the probe, and do not duplicate them in the attach. This means that all probes, even those that use completely out-of-band detection methods (eg. PnP) have to pretend to probe the "old" way. > - It is becoming really hard to port something from/to FreeBSD to/from > NetBSD or BSDI. You can point fingers in any direction here. It's hard to come down on either side of the issue. > - There are many bus kind of hardware coming, for example, usb or > IEEE1394. If we don't have separate bus type for them, config file > will become too ugly. > NetBSD usb team uses bus named "usb" for this, and it looks really > clean. If we do it right, there won't *be* a config file entry for USB. I can't imagine it getting much cleaner than that. 8) > - New config gives a cleaner way to define relationship between > "parent" device and "child" device. This must be incorporated for > cleaner wdc/wd disk/atapi/whatever structure, and for parallel-port > bus. This is one of the strengths of the structures that new config builds, yes. > - Having foo_softc[NFOO] is A BAD THING, thinking about pci/isapnp > devices. We must avoid this. ... and this is a major reason to avoid static configuration entirely. > - The way to register interrupt is different between pci device and > isa device. It is cumbersome. Agreed. > I understand that FreeBSD-current kernel is targetted toward > LKM-centric approach, but I believe new config is inevitable for > future development of FreeBSD kernel. It is inevitable purely and simply if someone(s) stand up and do the work. If you can sell the basic idea, and make it clear that it will work for people (like me) that feel strongly about this architecture, then it will truly be inevitable. > I propose to have separate repository for a while for "new config" > migration (machine and disk is almost ready, hosted by jp.freebsd > camp), and merge it into freefall if completed. Perhaps it would be better to use a branch on the main repository? > If something is already decided about this topic, please give me > some pointer for the discussion archive. I do not want to spend > my time to this, if it will never be merged into. >From an entirely pragmatic perspective, "new" config is better than "old" config. It's not the solution we are looking for, but it's a step in the right direction. If the integration will be carried through to completion, then I would be inclined to offer my support (whatever that's worth 8). -- \\ 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806090414.VAA00467>