From owner-freebsd-hackers  Wed May 24 17:43:39 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id RAA29244
          for hackers-outgoing; Wed, 24 May 1995 17:43:39 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA29230
          ; Wed, 24 May 1995 17:43:18 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA07392; Thu, 25 May 1995 10:42:44 +1000
Date: Thu, 25 May 1995 10:42:44 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199505250042.KAA07392@godzilla.zeta.org.au>
To: bde@zeta.org.au, terry@cs.weber.edu
Subject: Re: Cyclades Driver/Multi-port Serial Card
Cc: bde@freefall.cdrom.com, br\ian@med\iac\ity.com, hackers@FreeBSD.org,
        jkh@freefall.cdrom.com, julian@ref.tfs.com
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>> large as the original driver).  I intend to make even larger changes so
>> that all the serial drivers use a common front end.  cy.c currently has
>> about 30K of code (out of 60K total) in common with sio.c.  rc.c and
>> cy.c are very similar.  They drive similar Cirrus Logic chips and are
>> based on sio.c for the non-hardware parts.

>If you put a common cannonical processing front end on things, then you
>are a god in my book!  My personal preference is for a module that is
>ldterm type seperable and shared with the console (I have a fetish for
>Streams).

I meant a front end for open() (there is lots of device-independent code
for bidirectional devices), pseudo-DMA interrupt handlers (only the lowest
level is very device-dependent), ...

I think you actually want non-common not-necessarily-canonical
processing: generate maximally efficient routines for certain devices,
line disciplines, and internal settings of the line disciplines and load
these into the kernel as required.  This is too hard for me.  I'll settle
for maximally efficient slip and ppp disciplines.

Bruce