On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote:
> > +
> > + if (tty) {
> > + tty_kref_put(tty); /* drop kref from tty_driver_lookup_tty() */
>
> Put the comment above the line?
>
Sure
> > + tty = ERR_PTR(-EBUSY);
> > + } else { /* Returns with the tty_lock held for now */
>
> I don't understand this comment.
>
This is same comment in tty_open_by_driver. Basically, tty_init_dev
returns tty locked so that it doesn't dissapear from underneath the
caller. I am not sure about the "for now" part of the comment. I'll
remove it.
> > + tty = tty_init_dev(driver, index);
> > + set_bit(TTY_KOPENED, &tty->flags);
> > + }
> > +out:
> > + mutex_unlock(&tty_mutex);
> > + tty_driver_kref_put(driver);
> > + return tty;
> > +}
> > +EXPORT_SYMBOL(tty_kopen);
>
> EXPORT_SYMBOL_GPL()? :)
>
Of course, will update
> > /**
> > * tty_open - open a tty device
> > --- a/include/linux/tty.h
> > +++ b/include/linux/tty.h
> > @@ -362,6 +362,7 @@ struct tty_file_private {
> > #define TTY_NO_WRITE_SPLIT 17 /* Preserve write boundaries to driver */
> > #define TTY_HUPPED 18 /* Post driver->hangup() */
> > #define TTY_LDISC_HALTED 22 /* Line discipline is halted */
> > +#define TTY_KOPENED 23 /* TTY exclusively opened by kernel */
>
> Minor nit, please use tabs here.
>
Will do
> Overall, the idea looks sane to me. Keeping userspace from opening a
> tty that the kernel has opened internally makes sense, hopefully
> userspace doesn't get too confused when that happens. I don't think we
> normally return -EBUSY from an open call, have you seen what happens
> with apps when you do this (like minicom?)
>
Yes, returning -EBUSY is a change in the interface. I will test against
applications like minicom before resubmitting this.
Thanks,
Okash
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
