linuxconsole-dev

Re: What do we do (test7)?

[Vojtech P. <vo...@su...>]

On Sat, Aug 26, 2000 at 09:28:37AM -0400, James Simmons wrote:

> Okay. I think we should leave things as they are. We will see what happens
> when 2.5.X comes around are where things go. As long as the input suite
> stays I'm happy. For those that didn't follow the thread linus considered
> removing the input system :-( 

I don't think he was very serious about that, though.

-- 
Vojtech Pavlik
SuSE Labs

Re: Latest CVS results

[James S. <jsi...@ac...>]

> On Sun, Aug 20, 2000 at 08:11:11PM -0400, jsi...@ne... wrote:
> 
> >   Testing with what is in CVS. Using atkbd.c I discovered that it didn't
> > know what my delete key was. It did before. Because of this I couldn't
> > give the 3 finger salute. 
> 
> Ok, fixed.

Thank you. Will go play now.

Re: What do we do (test7)?

[James S. <jsi...@ac...>]

> > mice drivers to go. I got no response. Vojtech did linus speak to you
> > about this?
> 
> No, he did not. I can see several scenarios:
> 
> 1) Leave drivers/usb as is, move the rest to drivers/input
> 2) Leave everything where is, just convert to use the input core over time
> 3) Create drivers/char/mice, drivers/char/keyboards, a la
> drivers/char/joysticks
> 
> I think 2) is most likely to happen. I don't care much, as long as the
> functionality is maintained.

Okay. I think we should leave things as they are. We will see what happens
when 2.5.X comes around are where things go. As long as the input suite
stays I'm happy. For those that didn't follow the thread linus considered
removing the input system :-( 

Re: Latest CVS results

[Vojtech P. <vo...@su...>]

On Sun, Aug 20, 2000 at 08:11:11PM -0400, jsi...@ne... wrote:

>   Testing with what is in CVS. Using atkbd.c I discovered that it didn't
> know what my delete key was. It did before. Because of this I couldn't
> give the 3 finger salute. 

Ok, fixed.

-- 
Vojtech Pavlik
SuSE Labs

Re: What do we do (test7)?

[Vojtech P. <vo...@su...>]

On Fri, Aug 25, 2000 at 02:05:53PM -0400, Brad Douglas wrote:
> I like #3, but it also brings up Eric's concern of code not getting updated.
> But then again, if we could split it up like that, then why not just have
> drivers/input as desired?
> 
> #2 is most likely and it should be moved in that direction until Linus can
> be convinced otherwise.
> 
> We shouldn't waste too much time with this.  It isn't all that important to
> the overall functionality.

I think we can keep the CVS as is, possibly moving the joystick and USB
code to the same places they are now in the kernel, to allow for minimal
diffs. Neither we nor anyone else can predict where the files will end
up in the final version, so I think we shouldn't worry too much about
that. As shown, it's just trivial changes in the Makefiles.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Jeff R. <ra...@bi...>]

Linus Torvalds wrote:

>On Mon, 21 Aug 2000, Philipp Rumpf wrote:
>>On Mon, Aug 21, 2000 at 12:02:03PM -0700, Linus Torvalds wrote:
>>>Yes, people always worry about common chips, but they don't happen all
>>>that often in the end, and the pain from trying to share the code is
>>>usually much MUCH bigger than the pain from just occasionally stealing
>>>code from the other guy.
>> 
>>So you think it's a good thing we have 5 serial drivers rather than one, and
>>it'd be a good thing to split up the one we have into several drivers again ?
> 
> Probably.
> 
> Which does not mean that we should just duplicate all the code. The same
> way we don't duplicate the whole TCP/IP stack for each network card
> driver. There are tons of common issues in serial cards, and it's probably
> a good idea to have common code. But you should not take it too far.
> 
> I think the current serial.c is starting to be a major mistake. That one
> driver tries to handle everything from the original 16450 all the way up
> to serial multi-port cards that happen to just be multiple 16550's with
> some tweaks. As a result, the driver is quite complex and huge and is a
> mess of #ifdef CONFIG_xxx.

IMHO, it would be a GoodThing(tm) to move more things into the domain
of the Line Discipline when the next rewrite of the serial driver happens.
This would make it easier to share code across serial drivers.

When I spoke with Ted Ts'o at LWE last week, he seemed to be planning
to move in that direction post 2.4.


>>I think what might be saving us right now is that there is only one
>>widely-used bus architecture (PCI and it's derivatives/predecessors),
>>so no-one is going to implement conflicting new features in both parts
>>of a split driver.
> 
> And this is not going to change. Everything but PCI is dead, and there
> isn't going to be multiple different buses. Sure, we'll have some serial
> new-generation stuff, and we'll continue to have things like USB, but I'm
> not worried about having the same chip on different buses. It'
> s a thing of the past.

Not so much the same chip, but the same protocol for intelligent devices
across different busses -- the old Central Data (now Digi) Scsi Terminal
Server and EtherLites use the same intelligent protocol over both SCSI and
Ethernet for example.  Future products are likely to use a common protocol
over Ethernet, PCI and USB.

Notionally, these drivers have three layers (tty & LD, MUX, transport)
and generalizing this out to all cards where the MUX and transport layers
(or just transport when talking directly to UARTS) are all that needs
to be provided to add support for that card would be a big win.


-- 
Jeff Randall - Jef...@di...  "A paranoid person is never alone,
                                       he knows he's always the center
                                       of attention..."

Re: What do we do (test7)?

[Vojtech P. <vo...@su...>]

On Thu, Aug 24, 2000 at 10:31:04PM -0400, James Simmons wrote:

>   I don't how many people seen the long thread on the kernel mailing list
> but basically linus disagreed with the basic layout with the current
> linux-ruby CVS tree. Now that a input directory has been created and linus
> has spoken on his opinon should we modifiy are tree now to what linux
> wants? I sent a email to him asking where does he want future keyboard and
> mice drivers to go. I got no response. Vojtech did linus speak to you
> about this?

No, he did not. I can see several scenarios:

1) Leave drivers/usb as is, move the rest to drivers/input
2) Leave everything where is, just convert to use the input core over time
3) Create drivers/char/mice, drivers/char/keyboards, a la
drivers/char/joysticks

I think 2) is most likely to happen. I don't care much, as long as the
functionality is maintained.

-- 
Vojtech Pavlik
SuSE Labs

RE: What do we do (test7)?

[James S. <jsi...@ac...>]

On Fri, 25 Aug 2000, Brad Douglas wrote:

> I wasn't able to keep up with the whole thread, but I thought by the end of
> the thread he was more receptive to the concept, with the exception of HID.
> 
> Am I wrong?

Linus was actually considering getting ride of the input API. Only after
much pressure did he keep the api and create the input directory. If
you look at drivers/input only the files that have the core api are there. 

RE: What do we do (test7)?

[Brad D. <Br...@NE...>]

I wasn't able to keep up with the whole thread, but I thought by the end of
the thread he was more receptive to the concept, with the exception of HID.

Am I wrong?

Brad Douglas
br...@ne...
http://www.linux-fbdev.org


-----Original Message-----
From: James Simmons
To: Linux console project
Sent: 8/24/00 10:31 PM
Subject: What do we do (test7)?


Hi!

  I don't how many people seen the long thread on the kernel mailing
list
but basically linus disagreed with the basic layout with the current
linux-ruby CVS tree. Now that a input directory has been created and
linus
has spoken on his opinon should we modifiy are tree now to what linux
wants? I sent a email to him asking where does he want future keyboard
and
mice drivers to go. I got no response. Vojtech did linus speak to you
about this?

Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their
respective
owners.

What do we do (test7)?

[James S. <jsi...@ac...>]

Hi!

  I don't how many people seen the long thread on the kernel mailing list
but basically linus disagreed with the basic layout with the current
linux-ruby CVS tree. Now that a input directory has been created and linus
has spoken on his opinon should we modifiy are tree now to what linux
wants? I sent a email to him asking where does he want future keyboard and
mice drivers to go. I got no response. Vojtech did linus speak to you
about this?

Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their respective
owners.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Theodore Ts'o <ty...@va...>]

   Date: Wed, 23 Aug 2000 11:07:46 +0100 (BST)
   From: Alan Cox <al...@lx...>

   > No. That is just horrible. What's so wrong with simple flip-buffers that
   > they wouldn't work for you? Simple, and you can fill them up as fast as

   Our flip buffers dont work at 1Mbit or higher unless you hack
   HZ. However Ted thought of this ages ago. You don't have to use flip
   buffers on receive you can store frames however you like and the feed
   them directly to the tty input layer. Several smart interfaces do
   this.

Exactly.  Flip buffers are a service provided by the tty layer; much
like the various generic VFS functions provided by the VFS layer, device
drivers don't have to use them if they aren't useful given their
particular hardware and/or design goals.

						- Ted

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Alan C. <al...@lx...>]

> No. That is just horrible. What's so wrong with simple flip-buffers that
> they wouldn't work for you? Simple, and you can fill them up as fast as

Our flip buffers dont work at 1Mbit or higher unless you hack HZ. However Ted
thought of this ages ago. You don't have to use flip buffers on receive you
can store frames however you like and the feed them directly to the tty input
layer. Several smart interfaces do this

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Bjorn W. <bj...@sp...>]

On Tue, 22 Aug 2000, Linus Torvalds wrote:
> > SOmething similar to the skb's would be preferable - so I can just take
> > write blocks and chain them into the DMA hardware. Incoming data can go
> > into "skb's" as well up to the tty.
> 
> No. That is just horrible. What's so wrong with simple flip-buffers that
> they wouldn't work for you? Simple, and you can fill them up as fast as
> you can and then flip. Sure, if nobody reads the buffers fast enough
> you'll have trouble, but that's independent of how you do things. It's a
> basic law of the universe (called the "if nobody is listening, it doesn't
> matter how loudly or slowly you talk" law).

Ok a flip-buffer on receive which I DMA into is of course equivalent to
"skb"'s with a max outstanding count of 1 but without the allocation/free
code. So as long as the consumer eats the data quickly or the data is not
bursty that will work fine (and the other cases are probably to instable
to work with anyway, depending on if for example scheduling latencies are
a concern or not).

It was more on the output side I was thinking something more efficient
could be used than a copy into the write-buffer - but now that I think
about it, if we're to avoid pinning down user-pages, we still need to do
that copy somewhere so skb's wouldn't help there anyway...

Anyway, my main point was that I still hope to being able to DMA directly
into the tty flipbuffer etc. even if serial.c is split up, and I think
Rogier agreed there so all is well.. (ok actually we have our own
"serial.c" anyway but it would be nice to not having to duplicate all that
device-independant code eventually)

-Bjorn

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

On Tue, 22 Aug 2000, Bjorn Wesen wrote:
> 
> SOmething similar to the skb's would be preferable - so I can just take
> write blocks and chain them into the DMA hardware. Incoming data can go
> into "skb's" as well up to the tty.

No. That is just horrible. What's so wrong with simple flip-buffers that
they wouldn't work for you? Simple, and you can fill them up as fast as
you can and then flip. Sure, if nobody reads the buffers fast enough
you'll have trouble, but that's independent of how you do things. It's a
basic law of the universe (called the "if nobody is listening, it doesn't
matter how loudly or slowly you talk" law).

If you don't like the circular queues, you can just get rid of those.
Although I don't see what the difference between a circular queue and two
buffers you flip between really is. The circular queues work well for many
things, and are there because that's how the original tty layer worked..

		Linus

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Theodore Ts'o <ty...@va...>]

   Date: Tue, 22 Aug 2000 13:48:23 +0200 (MET DST)
   From: Bjorn Wesen <bj...@sp...>

   Forget the circular buffer and use a chain of buffers instead on the
   incoming queue. A circular buffer is just a fixed buffer-chain of 1-byte
   elements, but with an overflow headache and a flipping problem..

Trust me, you don't want to re-invent BSD clists.  They are a
performance disaster.

   A line discipline doing raw tty I/O can do zero-copy, in the sense that
   the serial driver on the receiving end gives away its received buffers to
   the upper levels. Just like in the network stack.

I verymuch doubt that given all of setup overhead and general
hair/complexity necessary for zero-copy, that this would be useful *at*
*all* in any real-life application.  The code is already optimized for
single-copy; given the relative speeds of serial transfer rates versus
memory copy speeds, this is a pointless optimization.

						- Ted

Re: [patch] The input move patch without moving to input

[James S. <jsi...@ac...>]

> I'd actually prefer drivers/input.
> 
> The argument I had against drivers/input was not an argument against a new
> subdirectory. It was an argument against moving the things like hid.c and
> the like to drivers/input, like the email I replied to tried to do.
> 
> hid.c is something USB-specific. It had better _not_ be a part of any
> "generic input layer". The same is true of usbkbd.c and friends. They are
> _usb_ drivers, and shall belong in drivers/usb.

Okay. I see your argument for the usb code. The question is where do we
put future non usb input drivers? The different types we can have are
mice, keyboards, and joysticks. Dump them where?  

Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their respective
owners.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [PATCH] Re: Move of input drivers, some word needed from you

[<R.E...@Bi...>]

Bjorn Wesen wrote:
> [incredible cc-list trimmed]
> 
> > We need an architecture similar to the net devices. 
> 
> agree
> 
> > The tty layer needs to set termios, and write characters. tty layer
> > should copy these into the circular buffer without leaving that to the
> > individual driver. (*) Usually the interrupt routine will just empty
> > the circular buffer.
> 
> I'd agree that the arch is very similar to net devices (network devices
> are in fact nothing else than a very specific form of serial devices :). 
> 
> BUT, by the same argument, the ol' circular buffer thingy needs to go as
> well. 
> 
> Example - our embedded CPU has full DMA to every I/O and the serial port
> can easily do 1.8 megabaud and has a 6 megabaud mode as well. Trying to
> get that to work with serial.c was a minor headache. Just because the PC
> still has shit-for-serial-ports should not be a limitation to scalability.
> 
> My solution was to let the driver DMA directly into the tty flipbuf while
> the sends still has to be copied into a buffer.
> 
> SOmething similar to the skb's would be preferable - so I can just take
> write blocks and chain them into the DMA hardware. Incoming data can go
> into "skb's" as well up to the tty.
> 
> My point is just that if we're going to go through the horror of
> completely redesigning serial.c we might as well get rid of the "char by
> char" mentality, at least not so that it limits the _fast_ ports out
> there.

Agreed. 

Part of my suggestion is that there may be more than one "I got input"
routines. 

Some devices may not be able to provide more than one char at a
time. Think 8250.

	ser_got_one_char (inb (port->base + DATA));

Others like CD1864 may be able to provide us with a number of valid
chars before we read them from the data register:

	nvc = inb (port->base + NR_VALID_CHARS);
	ser_got_chars_in_one_ioreg (port->base + DATA, nvc);

I also have a driver that would need:

	nchars = readb (port->base + CHARS_IN_BUFFER)
	ser_got_chars_in_iomem (port->base + BUFFER, nchars);

You'r suggesting that you'd like to do:

	nchars = readl (port->base + CUR_DMA_POINTER) - port->cur_buf;
	ser_got_chars_in_mem (port->cur_buf, nchars);
	port->cur_buf = kmalloc (BUFSIZE);
	writel (port->base + CUR_DMA_POINTER, virt_to_bus (port->cur_buf));

Now having something like skbuffs internally may make more sense if
you think about passing those buffers around. Point is: the driver
shouldn't need to know.



					Roger. 

-- 
** R.E...@Bi... ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*       Common sense is the collection of                                *
******  prejudices acquired by age eighteen.   -- Albert Einstein ********

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Bjorn W. <bj...@sp...>]

[incredible cc-list trimmed]

> We need an architecture similar to the net devices. 

agree

> The tty layer needs to set termios, and write characters. tty layer
> should copy these into the circular buffer without leaving that to the
> individual driver. (*) Usually the interrupt routine will just empty
> the circular buffer.

I'd agree that the arch is very similar to net devices (network devices
are in fact nothing else than a very specific form of serial devices :). 

BUT, by the same argument, the ol' circular buffer thingy needs to go as
well. 

Example - our embedded CPU has full DMA to every I/O and the serial port
can easily do 1.8 megabaud and has a 6 megabaud mode as well. Trying to
get that to work with serial.c was a minor headache. Just because the PC
still has shit-for-serial-ports should not be a limitation to scalability.

My solution was to let the driver DMA directly into the tty flipbuf while
the sends still has to be copied into a buffer.

SOmething similar to the skb's would be preferable - so I can just take
write blocks and chain them into the DMA hardware. Incoming data can go
into "skb's" as well up to the tty.

My point is just that if we're going to go through the horror of
completely redesigning serial.c we might as well get rid of the "char by
char" mentality, at least not so that it limits the _fast_ ports out
there.

> Now, currently, most of the recieve handling is postponed to the
> bottom half. I question the usefulness of this optimization. It
> certainly adds latency. What is it that needs to be done on reception
> of a few chars? Copy the data to userspace, and hit the waitq of the
> process that's waiting for data. If you want to prevent the races, use
> a kernel-space circular buffer, and do the processing (copy to
> userspace) in the context of the wokenup process.

Forget the circular buffer and use a chain of buffers instead on the
incoming queue. A circular buffer is just a fixed buffer-chain of 1-byte
elements, but with an overflow headache and a flipping problem..

> It's not as if this is highly time-consuming: we already have to copy
> the data somewhere, so that part is "unavoidable". And the possibly

A line discipline doing raw tty I/O can do zero-copy, in the sense that
the serial driver on the receiving end gives away its received buffers to
the upper levels. Just like in the network stack.

> just enable tx buffer empty interrupts. On others it may have to push
> a buffer full of data onto the card (for example, sx doesn't interrupt
> for tx_empty unless the buffer was previously filled).

Just don't think all serial HW's do char-by-char or have buffers that go
empty. 

-Bjorn

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Vojtech P. <vo...@su...>]

Hi!

This sounds very very nice, almost unreal. Even for the USB modem /
serial drivers it'd make them much simpler and cleaner.

Vojtech

On Tue, Aug 22, 2000 at 02:16:51PM +0200, Rogier Wolff wrote:

> It is not quite that bad. 
> 
> We need an architecture similar to the net devices. 
> 
> tty layer just need a few callbacks.
> 
> The tty layer needs to set termios, and write characters. tty layer
> should copy these into the circular buffer without leaving that to the
> individual driver. (*) Usually the interrupt routine will just empty
> the circular buffer.
> 
> The serial driver needs to report "here is another char". That might
> be an inline function.
> 
> The serial driver also should be able to report "here is a bunch of
> chars in IO memory". There are a few more possibilities.
> 
> Initial implementation of the improved tty layer may implement that
> the trivial way, but it can be enormously optimized almost trivially
> too. 
> 
> Now, currently, most of the recieve handling is postponed to the
> bottom half. I question the usefulness of this optimization. It
> certainly adds latency. What is it that needs to be done on reception
> of a few chars? Copy the data to userspace, and hit the waitq of the
> process that's waiting for data. If you want to prevent the races, use
> a kernel-space circular buffer, and do the processing (copy to
> userspace) in the context of the wokenup process.
> 
> Similarly, a line discipline like "ppp" will just scan the chars for
> the end-of-packet char while copying the data to the reception skbuf.
> It's not as if this is highly time-consuming: we already have to copy
> the data somewhere, so that part is "unavoidable". And the possibly
> more expensive part is the "packet recieved". We already call that
> from the interrupt routine many more times per second for the 100mbps
> ethernet cards.
> 
> Oh, with DCD and stuff, we also need a callback for "modem signals
> changed". What to do with that (i.e. unblock someone in open, or
> hangup the users shell) should be the tty layer's choice. Not
> something that is done in the hardware driver.
> 
> A driver would implement:
> 
> 	open   /* Just the bare "tell the hardware we're now 
> 	          interested in various things like CD. */
> 	close  /* nobody interested anymore. Disable interrupts
> 		  for this device. */
> 	get_modemsignals /* report the modem signals */
> 	set_modemsignals /* Set the modem signals */
> 
> 	tx_buffer_nonempty /* Call to use when tx buffer becomes
> 				nonempty */
> 	change_termios /* termios changed. returns termios settings NOT
> 			implemented in the hardware. */
> 
> and performs callbacks from the interrupt routine for:
> 	- reception of characters
> 	- modem status change
> 
> Getting a callback for a modem status change (e.g. CD dropped) while
> that is currently ignored is not a problem. This doesn't happen that
> often.
> 
> tx_buffer_nonempty will, on some chips (e.g. 16550 and compatible)
> just enable tx buffer empty interrupts. On others it may have to push
> a buffer full of data onto the card (for example, sx doesn't interrupt
> for tx_empty unless the buffer was previously filled).
> 
> The standard open routine will all the open routine followed by
> set_modemsignals to set rts/dtr. Next, get_modemsignals is called to
> check for DCD.
> 
> This certainly CANNOT happen for 2.4, and it's a lot of work to get to
> the level that we currently have with the current structuring.
> 
> generic_serial is a step in the right direction, but it certainly
> isn't the best way to do things.
> 
> 				Roger.
> 
> 
> (*) Just like filesystem or device drivers change file->ops to point
> to their own "ops" structure, that is what a "super intelligent"
> serial driver would do if it didn't want the automatic "write copies
> into circular buffer". Or we could have a write routine anyway, which
> most drivers wouldn't implement as they wanted the fallback
> copy-to-circular buffer....
> 
> -- 
> ** R.E...@Bi... ** http://www.BitWizard.nl/ ** +31-15-2137555 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> *       Common sense is the collection of                                *
> ******  prejudices acquired by age eighteen.   -- Albert Einstein ********
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj...@vg...
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Re: Move of input drivers, some word needed from you

[<R.E...@Bi...>]

David Woodhouse wrote:
> 
> tor...@tr... said:
> >  A lot of serial.c is actually completely hardware-independent, and
> > serial.c in many ways is already "two drivers", in that it both knows
> > how to handle the low-level hardware AND it knows how to handle the
> > higher-level issues. And I don't think it would be bad to split it up
> > some more. 
> 
> The problem is that if you start to decouple the chipset driver from the 
> code which knows how to access the chip, you end up with lots of horrible 
> indirect function calls in the inner loops. This isn't really going to help 
> improve performance - and the serial driver has one of the biggest problems 
> w.r.t latency already.
> 
> I figure I can get away with it for the MTD code (see the interaction 
> between the CFI chipset code and the 'map' modules) because flash is 
> generally slow as hell anyway, but for serial it's just not that feasible.
> 
> We have the same problem when readb() becomes something other than a 
> #define or inline function.
> 
> One possibility for serial might be to reuse the generic chipset code in
> source form rather than object form - i.e. define serial_readb() et al.
> functions for your particular board/bus/mapping and then 
> #include <generic_16550.c>. That's quite ugly though.

It is not quite that bad. 

We need an architecture similar to the net devices. 

tty layer just need a few callbacks.

The tty layer needs to set termios, and write characters. tty layer
should copy these into the circular buffer without leaving that to the
individual driver. (*) Usually the interrupt routine will just empty
the circular buffer.

The serial driver needs to report "here is another char". That might
be an inline function.

The serial driver also should be able to report "here is a bunch of
chars in IO memory". There are a few more possibilities.

Initial implementation of the improved tty layer may implement that
the trivial way, but it can be enormously optimized almost trivially
too. 

Now, currently, most of the recieve handling is postponed to the
bottom half. I question the usefulness of this optimization. It
certainly adds latency. What is it that needs to be done on reception
of a few chars? Copy the data to userspace, and hit the waitq of the
process that's waiting for data. If you want to prevent the races, use
a kernel-space circular buffer, and do the processing (copy to
userspace) in the context of the wokenup process.

Similarly, a line discipline like "ppp" will just scan the chars for
the end-of-packet char while copying the data to the reception skbuf.
It's not as if this is highly time-consuming: we already have to copy
the data somewhere, so that part is "unavoidable". And the possibly
more expensive part is the "packet recieved". We already call that
from the interrupt routine many more times per second for the 100mbps
ethernet cards.

Oh, with DCD and stuff, we also need a callback for "modem signals
changed". What to do with that (i.e. unblock someone in open, or
hangup the users shell) should be the tty layer's choice. Not
something that is done in the hardware driver.

A driver would implement:

	open   /* Just the bare "tell the hardware we're now 
	          interested in various things like CD. */
	close  /* nobody interested anymore. Disable interrupts
		  for this device. */
	get_modemsignals /* report the modem signals */
	set_modemsignals /* Set the modem signals */

	tx_buffer_nonempty /* Call to use when tx buffer becomes
				nonempty */
	change_termios /* termios changed. returns termios settings NOT
			implemented in the hardware. */

and performs callbacks from the interrupt routine for:
	- reception of characters
	- modem status change

Getting a callback for a modem status change (e.g. CD dropped) while
that is currently ignored is not a problem. This doesn't happen that
often.

tx_buffer_nonempty will, on some chips (e.g. 16550 and compatible)
just enable tx buffer empty interrupts. On others it may have to push
a buffer full of data onto the card (for example, sx doesn't interrupt
for tx_empty unless the buffer was previously filled).

The standard open routine will all the open routine followed by
set_modemsignals to set rts/dtr. Next, get_modemsignals is called to
check for DCD.

This certainly CANNOT happen for 2.4, and it's a lot of work to get to
the level that we currently have with the current structuring.

generic_serial is a step in the right direction, but it certainly
isn't the best way to do things.

				Roger.


(*) Just like filesystem or device drivers change file->ops to point
to their own "ops" structure, that is what a "super intelligent"
serial driver would do if it didn't want the automatic "write copies
into circular buffer". Or we could have a write routine anyway, which
most drivers wouldn't implement as they wanted the fallback
copy-to-circular buffer....

-- 
** R.E...@Bi... ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*       Common sense is the collection of                                *
******  prejudices acquired by age eighteen.   -- Albert Einstein ********

Re: [patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

On Tue, Aug 22, 2000 at 12:05:03PM +0200, Vojtech Pavlik wrote:
> On Tue, Aug 22, 2000 at 11:43:26AM +0200, Vojtech Pavlik wrote:
> > On Mon, Aug 21, 2000 at 08:43:37PM -0700, Linus Torvalds wrote:
> > 
> > > On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> > > > 
> > > > This one moves just the non-USB stuff of the input drivers out of
> > > > drivers/usb. That is, the bus-independent userland interface (char
> > > > device) modules. It places them in drivers/char. And modifies the
> > > > Makefiles and Config.in's accordingly.
> > > 
> > > I'd actually prefer drivers/input.
> > > 
> > > The argument I had against drivers/input was not an argument against a new
> > > subdirectory. It was an argument against moving the things like hid.c and
> > > the like to drivers/input, like the email I replied to tried to do.
> > > 
> > > hid.c is something USB-specific. It had better _not_ be a part of any
> > > "generic input layer". The same is true of usbkbd.c and friends. They are
> > > _usb_ drivers, and shall belong in drivers/usb.
> > 
> > Ok. Here is a patch that does that. Any more objections?
> 
> Replying to myself: This doesn't work. iforce.c (using both serial and
> USB interfaces) doesn't get compiled in correctly when only serial
> interface is selected.
> 
> More work ahead.

Done now. Please check this patch if it's OK. It moves iforce.c out of
drivers/usb, but that's necessary. Anyway, iforce.c is more a joystick
driver than an USB driver.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Philipp R. <pr...@pa...>]

On Tue, Aug 22, 2000 at 11:39:30AM +0100, David Woodhouse wrote:
> 
> tor...@tr... said:
> >  A lot of serial.c is actually completely hardware-independent, and
> > serial.c in many ways is already "two drivers", in that it both knows
> > how to handle the low-level hardware AND it knows how to handle the
> > higher-level issues. And I don't think it would be bad to split it up
> > some more. 
> 
> The problem is that if you start to decouple the chipset driver from the 
> code which knows how to access the chip, you end up with lots of horrible 
> indirect function calls in the inner loops. This isn't really going to help 

indirect function calls aren't that expensive anymore.  especially when you
consider CPUs at 500 MHz and PCI still running at 33 MHz, a few cycles for
an indirect call aren't all that terrible.

> improve performance - and the serial driver has one of the biggest problems 
> w.r.t latency already.

The serial driver suffers from other drivers leaving interrupts disabled for
too long.  Making the calls indirect wouldn't be a problem (except on old
386-class machines, that is).

> We have the same problem when readb() becomes something other than a 
> #define or inline function.

It is in generic alpha kernels.

> One possibility for serial might be to reuse the generic chipset code in
> source form rather than object form - i.e. define serial_readb() et al.
> functions for your particular board/bus/mapping and then 
> #include <generic_16550.c>. That's quite ugly though.

yuck.

	Philipp

Re: [PATCH] Re: Move of input drivers, some word needed from you

[David W. <dw...@in...>]

tor...@tr... said:
>  A lot of serial.c is actually completely hardware-independent, and
> serial.c in many ways is already "two drivers", in that it both knows
> how to handle the low-level hardware AND it knows how to handle the
> higher-level issues. And I don't think it would be bad to split it up
> some more. 

The problem is that if you start to decouple the chipset driver from the 
code which knows how to access the chip, you end up with lots of horrible 
indirect function calls in the inner loops. This isn't really going to help 
improve performance - and the serial driver has one of the biggest problems 
w.r.t latency already.

I figure I can get away with it for the MTD code (see the interaction 
between the CFI chipset code and the 'map' modules) because flash is 
generally slow as hell anyway, but for serial it's just not that feasible.

We have the same problem when readb() becomes something other than a 
#define or inline function.

One possibility for serial might be to reuse the generic chipset code in
source form rather than object form - i.e. define serial_readb() et al.
functions for your particular board/bus/mapping and then 
#include <generic_16550.c>. That's quite ugly though.

--
dwmw2

Re: [patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

On Tue, Aug 22, 2000 at 11:43:26AM +0200, Vojtech Pavlik wrote:
> On Mon, Aug 21, 2000 at 08:43:37PM -0700, Linus Torvalds wrote:
> 
> > On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> > > 
> > > This one moves just the non-USB stuff of the input drivers out of
> > > drivers/usb. That is, the bus-independent userland interface (char
> > > device) modules. It places them in drivers/char. And modifies the
> > > Makefiles and Config.in's accordingly.
> > 
> > I'd actually prefer drivers/input.
> > 
> > The argument I had against drivers/input was not an argument against a new
> > subdirectory. It was an argument against moving the things like hid.c and
> > the like to drivers/input, like the email I replied to tried to do.
> > 
> > hid.c is something USB-specific. It had better _not_ be a part of any
> > "generic input layer". The same is true of usbkbd.c and friends. They are
> > _usb_ drivers, and shall belong in drivers/usb.
> 
> Ok. Here is a patch that does that. Any more objections?

Replying to myself: This doesn't work. iforce.c (using both serial and
USB interfaces) doesn't get compiled in correctly when only serial
interface is selected.

More work ahead.

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

On Mon, Aug 21, 2000 at 08:43:37PM -0700, Linus Torvalds wrote:

> On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> > 
> > This one moves just the non-USB stuff of the input drivers out of
> > drivers/usb. That is, the bus-independent userland interface (char
> > device) modules. It places them in drivers/char. And modifies the
> > Makefiles and Config.in's accordingly.
> 
> I'd actually prefer drivers/input.
> 
> The argument I had against drivers/input was not an argument against a new
> subdirectory. It was an argument against moving the things like hid.c and
> the like to drivers/input, like the email I replied to tried to do.
> 
> hid.c is something USB-specific. It had better _not_ be a part of any
> "generic input layer". The same is true of usbkbd.c and friends. They are
> _usb_ drivers, and shall belong in drivers/usb.

Ok. Here is a patch that does that. Any more objections?

-- 
Vojtech Pavlik
SuSE Labs