Hi Alan,
> > As long as the new behavior continues to call
> > driver->close() if driver->open() succeeds
> > then I see no problem.
>
> It breaks if any existing driver is doing no cleanup in ->open() when it
> fails but relying upon ->close() being called. That is what needs
> auditing first
> > > > > 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
Alan Cox wrote:
It breaks if any existing driver is doing no cleanup in ->open() when it
fails but relying upon ->close() being called. That is what needs
auditing first of all.
Yes, I did not think of that.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the
> As long as the new behavior continues to call
> driver->close() if driver->open() succeeds
> then I see no problem.
It breaks if any existing driver is doing no cleanup in ->open() when it
fails but relying upon ->close() being called. That is what needs
auditing first of all.
-
To unsubscribe
Alan Cox wrote:
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 ?
As long as the new behavior continues to call
driver->close()
> > > > 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...
From: Oliver Neukum [mailto:[EMAIL PROTECTED]
> Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
> > > We find that a failure in open() leads to release_dev()
> being called.
> > > release_dev() calls close():
> > >
> > > if (tty->driver->close)
> > >
Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
> > We find that a failure in open() leads to release_dev() being called.
> > release_dev() calls close():
> >
> > if (tty->driver->close)
> > tty->driver->close(tty, filp);
> >
> > So we have a file that's closed
From: [EMAIL PROTECTED]
> in tty_io.c::tty_open():
[snip]
> We find that a failure in open() leads to release_dev() being called.
> release_dev() calls close():
>
> if (tty->driver->close)
> tty->driver->close(tty, filp);
>
> So we have a file that's closed although open()
From: [EMAIL PROTECTED]
in tty_io.c::tty_open():
[snip]
We find that a failure in open() leads to release_dev() being called.
release_dev() calls close():
if (tty-driver-close)
tty-driver-close(tty, filp);
So we have a file that's closed although open() never
Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
We find that a failure in open() leads to release_dev() being called.
release_dev() calls close():
if (tty-driver-close)
tty-driver-close(tty, filp);
So we have a file that's closed although open() never
From: Oliver Neukum [mailto:[EMAIL PROTECTED]
Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
We find that a failure in open() leads to release_dev()
being called.
release_dev() calls close():
if (tty-driver-close)
tty-driver-close(tty, filp);
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
Alan Cox wrote:
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 ?
As long as the new behavior continues to call
driver-close() if
As long as the new behavior continues to call
driver-close() if driver-open() succeeds
then I see no problem.
It breaks if any existing driver is doing no cleanup in -open() when it
fails but relying upon -close() being called. That is what needs
auditing first of all.
-
To unsubscribe from
Alan Cox wrote:
It breaks if any existing driver is doing no cleanup in -open() when it
fails but relying upon -close() being called. That is what needs
auditing first of all.
Yes, I did not think of that.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line
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.
Hi Alan,
As long as the new behavior continues to call
driver-close() if driver-open() succeeds
then I see no problem.
It breaks if any existing driver is doing no cleanup in -open() when it
fails but relying upon -close() being called. That is what needs
auditing first of all.
I know
18 matches
Mail list logo
