> > > > > So we have a file that's closed although open() never
succeeded?
> > > >
> > > > That's correct! It's been a pain in my butt for years.
> > >
> > > How did you deal with that proctological issue?
> >
> > Just make sure the close() handles the situation properly. It makes
> > reference counting... fun.
> >
> > The serial driver has always handled it like this.
>
> I'm also not aware of any reason other than history, which means if
> someone cares to double check the other drivers there really shouldn't
be
> an obstacle to "fixing" this behaviour.
>
> Unless anyone knows different ?
Hi Alan!
>From our (Digi's) drivers history, I believe you tried "fixing" it back
in the Red Hat 7.1 days. =)
Sadly, our drivers still carry this legacy fix around.
o Red Hat 7.1 -- Kernel Compatibility Issues
Some 2.4 kernel-based distributions (Red Hat 7.1 included) have
a patch
applied to them which modifies the behavior of Linux when an
open of
a serial port is canceled (for instance, if an application is
waiting
for the carrier signal and a user hits CTRL-C to kill the
application)
With this behavior change, the device driver is unable to
cleanup its
internal data structures and the sane functioning of the driver
is
compromised. The classic symptom of this problem is that the
command
"lsmod", which (among other things) will return a count of the
applications using the device driver, will return a non-zero
value
even if all applications associated with the serial ports
are killed.
Unfortunately, it is impossible (from within the device driver)
to
determine which behavior is implemented in the running kernel.
However, Digi now provides a workaround to allow customers with
this
problem to change the Digi behavior to be compatible with these
"patched" kernels.
I know backwards compatibility in the kernel isn't a concern at all,
which has been made abundantly clear, (ie, stable_api_nonsense.txt),
but this will impact *all* out of tree serial drivers.
Just wanted to toss this out there.
Scott Kilau
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
