Date: Mon, 13 Mar 95 9:54:22 MST From: terry@cs.weber.edu (Terry Lambert) To: karl@bagpuss.demon.co.uk (Karl Strickland) Cc: hsu@cs.hut.fi, freebsd-hackers@freefall.cdrom.com Subject: Re: New Cyclades driver issues and status Message-ID: <9503131654.AA03228@cs.weber.edu> In-Reply-To: <199503130220.CAA02507@bagpuss.demon.co.uk> from "Karl Strickland" at Mar 13, 95 02:20:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I've suggested abstracting the cannonical processing module, queue > > management, and device abstraction (ala SCO) to increase the amount of > ^^^^^^^ > does SCO do something special in this regard? what you're describing > sounds to me like STREAMS (right?) -- are SCO STREAMS different to any > other STREAMS - or is what you are describing more SCO specific? No, I'm not suggesting Streams. It's have to be re-ported and still needs ldterm and other modules, not from AT&T sources. SCO has abstracted large hunks of the tty driver code from specific device instances. Specifically, smart board drivers insert data directly into clists then trigger an event. This is how the Computone boards work, and is precisely why the Computone boards failed in the Xenix >= 2.3 until they were patched (SCO changed the data block size from 32 to 24 bytes -- when you did high speed I/O such that more than 24 characters were queued, boom went your kernel). Streams would be *a* way, but I'd hardly suggest it as *the* way at this point in time. > > shared code and the treatment of serial cards as multiple controllers > > under a class driver (ala Julian's SCSI abstraction) before. > > > > Now I'll suggest it again. 8-). > > > > The problem is in driver writers not making their code modular or generic, > > which is the expedient soloution. I guess it depends on if you want a > > single driver working now, or all drivers working later. > > didnt you do a STREAMS like thing for *BSD? that'd be a good place for > the rest of us to start. (i know i know.. :-)) I did do one for 386BSD 0.1 patchkit 2. The only modules I ever ran were the TCP/IP networking code from Lachman and the ldterm and pty modules from SVR4. There are no native drivers written for it, which means no drivers. As you can probably imagine, this means that with DDI/DKI and other interfaces not being around, a *lot* of work is required to put it back into service. Diffs won't do. The majority of it is rewrite, not only because of this, but because I screwed up the priority banding and introduced a nice little bug in canput (an abomination before God anyway, since it it very MP unaware). I don't have access to as much dormant hardware as I once did, and it's hard for me to get a machine above the 1.1.5 level -- I'm not willing to upgrade my main box at this time, and the performance fall-off on the merged cache was disappointing enough to keep me wary. I've saved enough for a new machine, but an really torn because of the low resoloution on the internal displays on portables is supposed to be fixed this year (NEC has promised 1024x768), the MP machine I was negotiating on is now unavailable, and I recently got offered a real deal on a DEC Alpha PCI motherboard (DEC sells them for $1170). When I get a new machine, I'll probably be spending time on other issues first -- a portable means PCMCIA and power management, with accompaning hacks to the VM to murder/option out overcommit for the power management to support resume/suspend and better processer detection in init for power recovery. An MP machine means SMP work and kernel multithreading. The DEC board means I spend some time porting and trying to pull in NetBSD code (or moving to NetBSD or Linux for that box, both of which are more or less supported, though the Linux does have support for the PCI). Either way, it'll be some time before I can get the code up to snuff, and I won't release it until it doesn't suck. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503131654.AA03228>