Date: Tue, 30 Mar 1999 14:39:05 +0900 From: Atsushi Furuta <furuta@sra.co.jp> To: paul@originative.co.uk Cc: freebsd-mobile@freebsd.org Subject: RE: Which LAN PCCARD for FreeBSD (no PAO!) Message-ID: <19990330143905B.furuta@sra.co.jp> In-Reply-To: Your message of "Mon, 29 Mar 1999 14:40:14 %2B0100" <A6D02246E1ABD2119F5200C0F0303D10FE85@octopus> References: <A6D02246E1ABD2119F5200C0F0303D10FE85@octopus>
next in thread | previous in thread | raw e-mail | index | archive | help
>> In article <A6D02246E1ABD2119F5200C0F0303D10FE85@octopus>, paul@originative.co.uk writes: >> * We already have a framework "subr_autoconf.c". >> It is not needed to invent new wheel. > I think actually the whole point was that a "new wheel" was needed to > support dynamic handling of devices. No, I don't think so. I admit that the code implemented in subr_autoconf.c does not handle dynamic aggregation and its handling of dynamic configuration is limited. But, since it is possible to add these features to the framework of subr_autoconf.c, subr_bus.c is a new wheel. Thus we are adding the feature of dynamic device handling to subr_autoconf.c >> * new-bus does not provide to "priority probe" feature. > No, but we have talked about supporting this on the new-bus list. Ok, you admit that priority probe feature is required and is lacking in current new-bus. We recognized the importance of priority probe from the start and coped with that problem. Since many drivers of FreeBSD assumes that attach() comes just after probe(), it will be a large work to remove this assumption from all the code. >> * new-bus remains old config(8) and old bus such as ISA. >> What we need is the reformation of them, so we can not >> adopt it. > I'm not quite sure what you mean here. It does currently use the existig > config(8) but that is not central to the issue of new-bus. As the work gets > completed the aim is to make the handling of devices totally dynamic. What > role the current static oriented config(8) will play isn't completely > determined. I understand that config(8) is not playing a central roll, but I do think that current new-bus can not handle well the ISA devices. The database generated by config(8) is required to use ISA devices after all. We want such dirty tool removed as early as possible, as we had many troubles with isa_devtab of config(8). Perhaps new-bus trusts the data from the bus for self-parametric device (or device on PnP bus), but a way to specify the parameters by the user should be left because there are always devices that do not conform to the standard. From this point we require a syntax to specify flexibly the parameters. This is the reason why we think config.new(8) is good. Yes, another tool to process such syntax would be required for dynamic configuration, but it should be easily achieved changing config.new(8). >> * There is no framework to separate bus-dependent part >> of a driver from bus-independent part in new-bus, >> but newconfig has. Many PC-card driver shares core code from >> another buses, so we reuqire such a framework. > That's not true, this is an area where new-bus already has everything well > established. Well, I apologize for my mistake. But new-bus does not give a "framework" to separate the device driver frontend (bus dependent part such as ed_isa.c) and device driver backend (bus independent part such as ed.c) as newconfig has. Am I wrong? >> * new-bus scatters device tree structure informations into >> each driver codes. Aproach to center the informations >> is better >> than scatter it. (Please imagine "LINT" file informations are >> scattered to each driver.) > I don't really understand what you mean by this either. What device tree > structure information are you referring to? In any case, you're approach of > using a central information source (e.g. LINT) fails to take into account > the dynamic nature of new-bus and it's ability to support third-party > supplied drivers. These drivers would need to be self-contained since they > are not developed by the project but by some third party and would need to > be able to install itself without changes to the installed system. My explanation was not good. What I wanted to say is, "device tree" information is required, which is well organized and can be referred from many tools. Device tree information keeps the information of which device is connected to which bus, as well as explanatory information of each device. We think the driver provided by the third party need not be "self-contained" but it is sufficient if such information is provided with the driver. The feature to pass dynamically such information to the kernel will be necessary. In newconfig, "files" file will play this role. Anyway, it is important that formal device tree information can be accessed by other tools. In new-bus, such informations are hard coded in the driver, isn't it? -- furuta@sra.co.jp (Atsushi Furuta) Advanced Technology Group. Software Research Associates, Inc. P.S. Almost all message of this is originally written in Japanese by me, and Tomoaki NISHIYAMA-san <tomoaki@biol.s.u-tokyo.ac.jp> translate to English. I thank him for the translation very much. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990330143905B.furuta>