Date: Mon, 29 Mar 1999 14:40:14 +0100 From: paul@originative.co.uk To: furuta@sra.co.jp, hosokawa@ntc.keio.ac.jp Cc: freebsd-mobile@freebsd.org Subject: RE: Which LAN PCCARD for FreeBSD (no PAO!) Message-ID: <A6D02246E1ABD2119F5200C0F0303D10FE85@octopus>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Atsushi Furuta [mailto:furuta@sra.co.jp] > Sent: 29 March 1999 14:26 > To: hosokawa@ntc.keio.ac.jp > Cc: freebsd-mobile@freebsd.org > Subject: Re: Which LAN PCCARD for FreeBSD (no PAO!) > > > >> In article <199903290121.KAA06196@afs.ntc.mita.keio.ac.jp>, > hosokawa@ntc.keio.ac.jp (HOSOKAWA Tatsumi) writes: > > > At least, *I* haven't moved to newconfig and neutral about it. I > > agree that new bus architecture is disired. But I have little > > knowledge about the technical differences between newconfig and > > new-bus. Somebody can explain it briefly? > > I am one of developers of newconfig, so I can not fairly evaluate > difference between newconfig and new-bus. Instead of it, please let me > explain why we are developing newconfig. > > Newconfig was derived from an opinion that there were not enough > framework of device configuration in FreeBSD (at least in those days). > We decided that we don't do temporary workarounds, and should reform > basis of the devices. There were some people (including me) who ports > drivers from NetBSD to FreeBSD for PAO. They were aware of elegant > device framework of NetBSD, so we tried to port it to FreeBSD. > > After we began the project, we were notified another framework > "new-bus". Then we discussed which we should change to new-bus or not. > We decided not to adopt new-bus. (If you can read Japanese, you can > read the discussion archive > http://www.jp.freebsd.org/mail-list/newconfig-jp/199806-month.html ) > > The reasons (which I understand) are: These are actually very inaccurate points regarding new-bus. > > * 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. > * new-bus does not provide to "priority probe" feature. No, but we have talked about supporting this on the new-bus list. > * 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. > * 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. > * 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. I think there is clear misunderstanding as to what new-bus is and why the project is so keen to pursue that direction. Paul. 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?A6D02246E1ABD2119F5200C0F0303D10FE85>