Re: [PATCH] New user space serial port driver
Pavel Machek wrote: > > Please consider including this user space serial driver. It was writen for > > the Pele 833 RAS Server but is also usable for other serial device drivers > > in user space. > > Good, someone finally implemented this. This is going to be mandatory > if we want to support winmodems properly; also ISDN people might be > interested [to kick AT emulation out of kernel]. For winmodems you can do a pretty good job with ptys -- the pty and tty side access the same share termios structure. The new driver is a much cleaner way to the same functionality though. (Conceptually; I looked at the API summary but haven't looked at the code). -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Hi! > Please consider including this user space serial driver. It was writen for > the Pele 833 RAS Server but is also usable for other serial device drivers > in user space. Good, someone finally implemented this. This is going to be mandatory if we want to support winmodems properly; also ISDN people might be interested [to kick AT emulation out of kernel]. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Russell King wrote:
> Rogier Wolff writes:
> > Documentation bug. Not code bug.
>
> In which case, can we put it in as a documentation fix rather than changing
> the compiler output? ie, /* = { NULL, } */ ?
Because I care more about the 4 bytes of extra source than the
4 bytes of extra object.
I consider the 4 bytes of extra object code a compiler bug, and if we
start catering for that, the bug in the compiler will never be fixed.
This is similar to how Linus forced the recognition of the
"unroll-loops" bug by the gcc team.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Rogier Wolff writes:
> Documentation bug. Not code bug.
In which case, can we put it in as a documentation fix rather than changing
the compiler output? ie, /* = { NULL, } */ ?
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Russell King wrote: > Rogier Wolff writes: > > > > +static struct termios* ussp_termios[USSP_MAX_PORTS]; > > > > +static struct termios* ussp_termios_locked[USSP_MAX_PORTS]; > > > > this SHOULD mean that these are first initialized before use. > > > > If you think they can be used before first being initialized by the > > code, then that's a bug, and I'll look into it. > > Ah, but they are initialised before use, by arch/*/kernel/head.S. > Therefore no bug exists. Documentation bug. Not code bug. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Rogier Wolff writes:
> > > +static struct termios* ussp_termios[USSP_MAX_PORTS];
> > > +static struct termios* ussp_termios_locked[USSP_MAX_PORTS];
>
> this SHOULD mean that these are first initialized before use.
>
> If you think they can be used before first being initialized by the
> code, then that's a bug, and I'll look into it.
Ah, but they are initialised before use, by arch/*/kernel/head.S.
Therefore no bug exists.
Are all these people who are saying "we should explicitly initialise
these variables" going to go through all user-space programs and fix
all those "bugs" which are there apparantly lying dormant as well?
I think they should. If not, then I'll scream pot black. ;) Exactly
the same arguments apply there as in the kernel. In fact even more
so - user space relies on the kernel to pass zeroed pages to user
space. What if clear_page() doesn't work properly?
I hasten to point out that Andries Brower's example about a week ago
doesn't really work too well. The quoted code was something along the
lines of:
/* case 1 */
static int foo = 0;
int bar()
{
... code that relies on foo to initially be zero ...
}
There were several arguments put forward. One of them was that the
following would be the same:
/* case 2 */
int bar()
{
int foo = 0;
... same code ...
}
These two are obviously not identical. The code will behave differently
in both cases if bar() is more than once. The first will see the result
of calling bar() the first time. The second case will always see foo as
zero.
However, as far as code and functionality is concerned, the first
case is identical declaring foo as:
/* case 3 */
static int foo; /* = 0 */
It contains the same documentary evidence as well, so there is no possible
argument that can be put forward to say that case 1 and case 3 do not
functionally behave the same *provided that head.S initialises BSS and we
compile with -fno-common to ensure that we catch duplicate declarations*.
The only difference between case 1 and case 3 is that case 3 uses less
file size.
Now, I'd ask the people who had the "documentation" argument, is case 3
acceptable to you?
Big note: I'm not interested in hearing from people who try to argue that
using the BSS is a bug. Mails with this content will be sent to /dev/null.
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Tigran Aivazian wrote:
> On Thu, 30 Nov 2000, Patrick van de Lageweg wrote:
> > +static struct tty_struct * ussp_table[USSP_MAX_PORTS] = { NULL, };
>
> this wastes at least 4 * USSP_MAX_PORTS bytes in the kernel image.
> Typically around 64 bytes but could be more. For more info see the recent
> silly flamewars on the list.
And I think the guys who were saying that the "documentation is more
important than those few bytes" were winning.
I am one of those guys. I think the documentation aspect is much more
important than those 64 bytes.
> The correct way is not to initialize the data
> to zero explicitly as BSS is cleared automatically on boot. It is also
> probably documented in the lkml FAQ at the bottom of this message.
>
> Also, it makes your code look consistent as, e.g. in cases below you do
> the right thing:
>
> > +static struct termios* ussp_termios[USSP_MAX_PORTS];
> > +static struct termios* ussp_termios_locked[USSP_MAX_PORTS];
this SHOULD mean that these are first initialized before use.
If you think they can be used before first being initialized by the
code, then that's a bug, and I'll look into it.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
On Thu, 30 Nov 2000, Patrick van de Lageweg wrote:
> +static struct tty_struct * ussp_table[USSP_MAX_PORTS] = { NULL, };
this wastes at least 4 * USSP_MAX_PORTS bytes in the kernel image.
Typically around 64 bytes but could be more. For more info see the recent
silly flamewars on the list. The correct way is not to initialize the data
to zero explicitly as BSS is cleared automatically on boot. It is also
probably documented in the lkml FAQ at the bottom of this message.
Also, it makes your code look consistent as, e.g. in cases below you do
the right thing:
> +static struct termios* ussp_termios[USSP_MAX_PORTS];
> +static struct termios* ussp_termios_locked[USSP_MAX_PORTS];
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
