> What about the not nice ways?
> Having a ugly driver until 3.7 is better than having no driver...
If you are willing to go do the work then yes.
> I'm wondering why does drivers/tty/vt/vt.c work?
> Can't I model the UML driver after it?
Possibly although the vt driver has its own locking model
On Thu, 07 Jun 2012 18:32:42 +0200
Richard Weinberger wrote:
> Am 07.06.2012 18:37, schrieb Alan Cox:
> > Yes I know exactly what is going on. However getting a more tolerant
> > behaviour is going to take a couple more kernels.
> >
>
> So, then please tell me what&
On Thu, 07 Jun 2012 17:18:37 +0200
Richard Weinberger wrote:
> Alan, Jiri!
>
> If I omit ->hangup(), mingetty (And all other getty implementations)
> are unable to open /dev/ttyX. open() returns -EIO.
> Currently I'm testing it on FC12.
> Also if I do something like "echo foo >/dev/tty1" it fail
On Thu, 07 Jun 2012 01:17:24 +0200
Richard Weinberger wrote:
> Am 04.06.2012 23:17, schrieb Alan Cox:
> > We can half ignore it on console for the simple reason that you
> > don't "dial in" to the console. I suspect it may be abusable but
> > I've not f
> Breaking existing applications is a no-go, sorry.
Being insecure should also be a no-no.
Not sure what Jiri thinks but for the moment I think we need to push it
with a module option as to whether hangup on console is enabled or not.
I don't want to just break the existing user space, but leavi
> > I really don't get it. You have not broken anything new. Only
> > not fixed all of the problems. Current code does not work for "non-tty0
> > terminals" as well right?
>
> No, it works fine.
Not really. You happen to be lucky. Anyway with no tty port the UML code
will soon cease to function c
> open_tty() closes all the old file descriptors after tty open:
It needs to close them before.
>
> vhangup();
> ...
> fd = open(tty, O_RDWR | O_NONBLOCK);
> ...
>
> flags = fcntl(fd, F_GETFL);
> flags &= ~O_NONBLOCK;
> fcntl(fd, F_SETFL, flags);
>
> f
> On all other ttys login works but bash dies because of of -EIO.
> After vhangup() the tty returns -EIO upon read()/write().
You can't re-open the tty because a process is holding on to it, not
closing it and not killable. Fedora shouldn't be holding these devices
open this way. The b
> Two days ago I did so but still faced the problems described here:
> https://lkml.org/lkml/2012/3/10/163
If you are running a Fedora like distro it's because the user space is
broken. At some point we are going to have to make them fix the userspace
not to sit with ttys held open.
Alan
--
On Fri, 27 Jan 2012 13:04:37 +0100
richard -rw- weinberger wrote:
> On Fri, Jan 27, 2012 at 12:51 PM, Alan Cox wrote:
> >> UML's console driver (arch/um/drivers/line.c) implements tty_operations.
> >> The crash happens because the tty subsystem calls the driver's
> UML's console driver (arch/um/drivers/line.c) implements tty_operations.
> The crash happens because the tty subsystem calls the driver's close()
> function and later
> write_room() or chars_in_buffer().
>
> write_room() and chars_in_buffer() fail badly because close() already
> cleaned up the d
On Sat, 7 Nov 2009 13:16:18 -0200
André Goddard Rosa wrote:
> On the following sentence:
> while (*s && isspace(*s))
> s++;
Looks fine but for one thing: it's actually shorter inline than moved
into /lib so at the very least it should be a header inline not a
function call.
Second
On Tue, 22 Jul 2008 18:35:09 +0100
WANG Cong <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 22, 2008 at 11:53:54AM +0100, Alan Cox wrote:
> >> Signed-off-by: Eric Sesterhenn <[EMAIL PROTECTED]>
> >>
> >> --- linux-2.6/arch/um/drivers/line.c.orig
WRITE_WAKEUP, &tty->flags))
> + tty_wakeup(tty);
Sorry I should have been clearer - you don't want the test_bit either.
Acked-by: Alan Cox <[EMAIL PROTECTED]>
however as it is still right but you can stick my Ack on a version
without the if too.
-
On Mon, 21 Jul 2008 17:54:09 +0100
WANG Cong <[EMAIL PROTECTED]> wrote:
>
> Fixed this build error:
>
> /home/wangcong/Projects/linux-2.6/arch/um/drivers/line.c: In function
> ‘line_write_interrupt’:
> /home/wangcong/Projects/linux-2.6/arch/um/drivers/line.c:366: error:
> ‘struct tty_ldisc’ has
ECTED]>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting ev
Jeff this is the tty locking diff I mentioned at Linux Kongress, it just
ensures current->signal->tty doesn't get freed during log_exec().
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.18-rc6-m
1/arch/um/drivers/chan_kern.c
> =======
Acked-by: Alan Cox <[EMAIL PROTECTED]>
(and applied to my tty tree for future diff generation)
---
SF.Net email is Sponsored by the Better Software Confere
On Mer, 2005-04-27 at 18:46, Chris Wright wrote:
> > Don't see why this one is a critical bug.
>
> I guess without it, modular nfsd has no syscall interface (for UML, or
> course).
And the trivial zero risk fix is to compile it in. Its hardly pressing
--
On Mer, 2005-04-27 at 18:15, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
Don't see why this one is a critical bug.
---
SF.Net email is sponsored by: Tell us your software development plans!
Take t
20 matches
Mail list logo
