1) I have built a multifunction driver to support the Aurora
Technologies, Inc. serial adapter cards and expansion units that use
Siemens/Infineon SAB 82532 and SAB 82538 (ESCC2 and ESCC8) enhanced
serial communications controllers. This driver supports asynchronous
TTYs, synchronous TTYs, an Ethernet-like synchronous serial Network
driver, and a packet-oriented character device to facilitate the
portation to Linux of synchronous protocol applications that have been
implemented with putmsg and getmsg on proprietary Unix systems. (A
patch for those interested in trying the driver will be put up on one
of my web pages shortly.) I took the SPARC Linux SAB 82532 serial
asynchronous TTY driver as a starting point and kept the
block_til_ready logic that arbitrates access between the cua and ttyS
devices because it seemed helpful in arbitrating access to a physical
port among the asynchronous TTY, asynchronous call out, synchronous
TTY, Network and character device functionalities. From reviewing the
archive, I noticed that the cua devices have been deprecated, and that
now apparently callout and asynchronous terminal connectivity are
supposed to be managed through a single port. I am not sure how
asynchronous dialout for synchronous TTYs, synchronous Network devices
and the synchronous character device can be managed without a separate
asynchronous callout device to communicate with the modem before the
synchronous connection is set up. I suppose I could modify the
asynchronous TTY device so that it could be bimodal and switch back
and forth between synchronous and asynchronous mode, but a similar
procedure would be hard for the synchronous character device and very
hard for the synchronous network device. How is dialout supposed to
be handled for asynchronous dialup modems that can set up synchronous
point-to-point connections on demand?
2) Are the other PCI or (E)ISA serial adapter cards that use the
SAB82532 and SAB82538 enhanced serial communications controller?
I could add support for them into this driver.
3) Aurora wants to track the driver in its source control system, but
they have ISO 900X procedures that require maintaining the build
environment under CVS. The build environment is basically the kernel
against which it is developed. But new developer kernels are released
fairly regularly (unlike new versions of Solaris or True64). Do
maintainers of such driver software commonly maintain development
environments across a complete range (e.g., all 2.4.* kernels)? Is
there a FAQ with recommendations to help a hardware vendor deal with
the nitty gritty details of making sure its driver software works
properly across such a range of rapidly changing development
environments?
Joachim Martillo
Telford Tools, Inc.
[email protected]
> 3) Aurora wants to track the driver in its source control system, but
> they have ISO 900X procedures that require maintaining the build
> environment under CVS. The build environment is basically the kernel
> against which it is developed. But new developer kernels are released
> fairly regularly (unlike new versions of Solaris or True64). Do
> maintainers of such driver software commonly maintain development
> environments across a complete range (e.g., all 2.4.* kernels)? Is
> there a FAQ with recommendations to help a hardware vendor deal with
> the nitty gritty details of making sure its driver software works
> properly across such a range of rapidly changing development
> environments?
Generally driver vendors only certify/support against "standard" vendor
released kernels. So instead of Linux they support "SuSE 7.3" "Red Hat 7.2"
etc..
Most also make a clear distinction between what is submitted to the GPL and
hacked about under the GPL, and what they will provide any guarantee on.
Think of it like a car.
The engine is only supported for the car it was designed for
You can rebore the engine but you wont get support
You can stick the engine in a different car but you wont get support
Alan
On Wednesday 28 November 2001 21:12, Alan Cox wrote:
> > 3) Aurora wants to track the driver in its source control system, but
> > they have ISO 900X procedures that require maintaining the build
> > environment under CVS. The build environment is basically the kernel
> > against which it is developed. But new developer kernels are released
> > fairly regularly (unlike new versions of Solaris or True64). Do
> > maintainers of such driver software commonly maintain development
> > environments across a complete range (e.g., all 2.4.* kernels)? Is
> > there a FAQ with recommendations to help a hardware vendor deal with
> > the nitty gritty details of making sure its driver software works
> > properly across such a range of rapidly changing development
> > environments?
>
> Generally driver vendors only certify/support against "standard" vendor
> released kernels. So instead of Linux they support "SuSE 7.3" "Red Hat 7.2"
> etc..
>
> Most also make a clear distinction between what is submitted to the GPL and
> hacked about under the GPL, and what they will provide any guarantee on.
>
> Think of it like a car.
> The engine is only supported for the car it was designed for
> You can rebore the engine but you wont get support
> You can stick the engine in a different car but you wont get support
>
Unless they release it GPL, then it might be included in the kernel right?
And "the nitty gritty details of making sure its driver software works
properly across such a range of rapidly changing development
environments" taken care of by the users of the driver. They can even track
it by CVS, by requesting all patches against the driver to be submitted to
them.
They asked for official recommendations, shouldnt the primary recommandation
not be to open source it, even if some vendors wont?
Regards
> Unless they release it GPL, then it might be included in the kernel right?
> And "the nitty gritty details of making sure its driver software works
> properly across such a range of rapidly changing development
> environments" taken care of by the users of the driver. They can even track
> it by CVS, by requesting all patches against the driver to be submitted to
> them.
Seperate "works" from "supported by". Putting a driver in the kernel makes a
lot of sense, but you'd still probably have an officially supported version.
> They asked for official recommendations, shouldnt the primary recommandation
> not be to open source it, even if some vendors wont?
They have to open source it anyway, since it is based on the sbus aurora
driver as they said, so its already GPL code.
There is a difference between releasing GPL code and supporting it. Standard
Red Hat support contracts for example stop at the point you go compiling
your own kernel.