Date: Mon, 20 Sep 1999 16:35:01 -0600 From: Warner Losh <imp@village.org> To: Ade Lovett <ade@lovett.com> Cc: freebsd-mobile@FreeBSD.ORG, new-bus@FreeBSD.ORG Subject: Re: Combo 100Base-T Ethernet/10 BaseT Ethernet/Modem/ISDN cards Message-ID: <199909202235.QAA21098@harmony.village.org> In-Reply-To: Your message of "Mon, 20 Sep 1999 17:24:41 CDT." <19990920172441.R392@remarq.com> References: <19990920172441.R392@remarq.com> <19990920151102.J392@remarq.com> <199909202002.WAA68164@gratis.grondar.za> <19990920151102.J392@remarq.com> <199909202208.QAA20927@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <19990920172441.R392@remarq.com> Ade Lovett writes: : Absolutely. Hence the abstraction to an 'mfbus'. Provided (and I : realise this is an absolutely huge 'if'), there is at least some : degree of consistency in which the way multi-function cards are : implemented, surely this approach offers the cleanest way in to the : underlying devices. : : mfbus would be made up of two components, the generic core to which : the underlying devices would be attached, and an implementation-specific : part (mfbus_3com, mfbus_xircom etc.) Hmmm, it sounds almost like we're talking about the same thing.... : > The last thing in the world that I : > want is to have 100 different attachments for sio1 (one for Xircom, : > one for 3com, one for hayes, etc, etc, etc). : : Agreed. Though in this case, surely we'd only have to provide one : extra attachment (to mfbus_core) ? : : More bluntly, what are the alternative approaches? I've expanded on this in another message. The basic approach is that there will be a slot driver that can have multiple children. The slot driver is used even in the case of a single function card. That way we wouldn't need separate attachments for single function and multi-function cards. chances are good that we'd need cardbus and pccard attachments still since configuring things is different if nothing else between the two. : It seems that we're actually at a good point (what with the sio/nsio : stuff) to not only work out the issues with pccard modems, but also : to work out a good API into the CIS and memory mapping (so I can : unbreak the -current if_xe) and deal with Cardbus and multifunction : cards. Yes. I've started to come up for air. All know security advisories have been dealt with (the last one is in the pipeline waiting for it to be moved to ftp as I type) so I have some time to devote to this again. Also, the pccard nbk stuff is in the tree, which should relieve some pressure from the next generation of efforts. : Looking at any of these issues (and the hundreds I have undoubtedly : missed) in isolation is likely to cause us more pain and anguish down : the road. : : Judging by the amount of input on this thread, it certainly seems as : though there's a willingness to get this sorted, no? Yes. I've spent a lot of time thinking about how to move forward but little time actually moving forward over the past few months. My current plan is to take the in-kernel pccardd that is part of the newbus code and use that as a basis to move forward. The current pccard code is up side down to the direction that newbus is moving and would need to be fixed or replaced. Given the amount of fixing that has been done to it already, I believe that replacement may get us results more quickly. Given that we have dev/pccard in the tree now, we can start to use that as a platform from which to move forward. I'd like to move forward on the pccard issues while the various drivers we'd be interested in are de-isified by Peter, Doug and the other newbus folks. This will also let us learn what I did wrong it the new bus kludge I did and hopefully avoid similar mistakes in this go around. Comments? Warner P.S. I'm not sure if this discussion belongs in new-bus or mobile, so I've cc'd both... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909202235.QAA21098>