>    However I've added 3 new ioctl's (and I'm unsure how to define their
>    exact numbers). [...]
> 
> That's ... special, and silly.  If you're going to do this at all,
> it should be done in a device-independent fashion.  I'd suggest 
> adding a TCSADEFAULT (or some such thing) type for the `action'
> field to tcsetattr(), and otherwise reusing the same user API.

I'm sorry, but I don't understand why it's silly. I agree that being
device-independent is good, but since I'm only asking that this
functionality exist in the driver I'm willing to work on, this
functionality will be decidedly device-dependent.

I agree that a TCSCADEFAULT (or some such) would be the cleanest way to
impliment the setting of defaults. But looking at the code for
tcsetattr(), it would need changing. Thus adding the features I want in
the serial driver for the z8530 wold imply that everybody's libc has to
change (a new case has to be added to the switch statement), plus the
headers have to change, plus we still need a new ioctl verb, plus then
people will wonder why all the other drivers don't support TCSADEFAULT,
so the other driver writers would feel pressure to add to their code.

That strikes me as asking a lot of people to do stuff to accomodate what
I want, when they don't see any gain. I.E. it's less likely to happen.

If I just add a new ioctl verb to the driver, then I get what I want,
no one else is bothered, other drivers will ignore it, and all is well.

Also, I'm unsure how I'm breaking the API. All I'd add would be names
for _IO('t',unused_number_1), _IO('t', unused_number_2), and
_IO('t',unused_number_3). EVERYTHING else is the same unless someone
chooses to change a default. Then either the defaults are different,
or the `first open' behavior switches from the one used by about
half the serial drivers (always resetting defaults) to the behavior
used by the other half of the drivers (only set defaults on the
first `first open').

Take care,

Bill