Date: Wed, 10 Jun 1998 00:07:45 +0900 From: Jun-ichiro itojun Itoh <itojun@iijlab.net> To: Mike Smith <mike@smith.net.au> Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, tech-jp@jp.freebsd.org Subject: Re: new config Message-ID: <10481.897404865@coconut.itojun.org> In-Reply-To: mike's message of Mon, 08 Jun 1998 21:14:10 MST. <199806090414.VAA00467@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry that I was silent after starting the thread. I was dead busy today, too long meetings... (order of the quotation changed for some places) >Can you clarify when you talk about "new config", do you specifically >mean the "new config" tool, or an improved bus/resource/driver model? I think they will come together, but I'm talking about bus/resource/driver model, not the "new config" tool itself. More specifically, clearer bus identification/separation with "struct device" is what I really need. I really believe that the driver structure must be cleaned up, right away. (Maybe the subject "new config" made you misunderstand) >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. Just to clarify, I don't say that "new config" is the magic wand for LKM drivers and statically-linked drivers. The structure generated by "new config" is just for statically-linked drivers. Also, what I really want to push is driver clarification by using "struct device". Even if structure generated by "new config" is not a solution for LKM, it is very important for FreeBSD kernel as a whole. Even if FULL-LKM-FreeBSD day has come, you'll need some (or minimal) static configuration for, say, IDE hard drive or pcic/cardbus controller. Even if you have newly formatted "static" driver configuration table, LKMs are possible. Other BSDs are working on LKMs on new driver configuration table, so I think they do not make much difference. "new config" does not make a big difference to LKMs. >> - 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? As I said, you'll need minimal static configuration table, anyway. For that tree-recursive is order of magnitude better than per-bus configuration order. >> - PAO/laptop support people would like to have separate bus type >> for pccard and cardbus. Cardbus people feels that they cannot make >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. So, I need common management structure based on "struct device" for every drivers. >> - 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". I never said that "new config" is the magic wand for all the LKM problems. It is a just starting point for clarification. "new config" solves static part of kernel configuration. It changes nothing for LKM-based drivers, I believe. I have a question: do you have the solution for the problem you raised in the above? Even with FULL-LKM-FreeBSD, you'll have some static drivers in your minimal kernel anyway. How do you pass configuration parameter for those drivers? How do you pass configuration parameter for LKM drivers? If everything can be automatically probed, that's really nice, a system of the dream. However, we got many badly-behaving hardwares that cannot be automatically probed at all (for example, cardbus chipsets that left uninitialized by bad BIOS). Just for example, BSDI has /etc/boot.default as text-based kernel config modification file. It has ability to disable/enable drivers, define irq/iomem for isa drivers, and so forth. This makes GENERIC driver workable on most platforms. This kind of approach can solve parameter-passing problems for statically configured drivers. >> - 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. There were bunch of cardbus discussion in PAO group. The answer always end up with "current driver architecture depends too much onto isa. we can't go forward without bus type separation". >> - 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. Is it okay for you if FreeBSD is "left out" just by not integrating advanced device configuration structures (struct device)? I'm having too much troubles porting network code and driver code back and forth between three BSDs, and end up that FreeBSD kernel is too different from others... (maybe, this is just personal feeling...) >> 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. Alright, maybe I should send you the initial patch with some drivers modified... >> 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? We maybe think again about the plans, but I think there are too many non-committer workers. Also, to merge this in it needs some time. itojun 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?10481.897404865>