Menu
▾
▴
linuxconsole-dev
|
From: Linus T. <tor...@tr...> - 2000-08-21 21:02:37
|
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. 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. I would not be unhappy to have separate drivers for different chipsets, and even if you want to have the same driver for a 16450 and a 16550 (they _are_ quite close, after all), it's not clear that it makes sense to do the same thing for the multiport things etc. > 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. > I don't think "there aren't going to be a great many file in this directory" > is really a good argument against creating a directory, except for the very > special case that there would be no files at all in it. I think you're wrong. Logical naming and hierarchy are only helpers. If they lead to people finding the files more quickly and understanding them better, they are doing their job. If hierarchy leads to having to look more places, think about it more, and just more work, that hierarchy is BAD. It doesn't matter if it is logical or not. It sucks. It just ends up being in your way. We could create a subdirectory for each driver. In some cases we _do_ that (tulip and ide come to mind). But in the end, it should be done only when it clarifies things, not just because somebody thinks it "ought" to be that way. And "there aren't going to be many files in this directory" is an argument against it. It means that the directory doesn't end up clarifying things very much at all. Linus |
|
From: Alan C. <al...@lx...> - 2000-08-21 21:07:33
|
> 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. There are two or three cards that are well weird - but trying to maintain a seperate driver for that would be a real nightmare. Possibly the access functions need more abstraction but its pretty well done as is > 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. generic_serial.c - mission already in progress for some cards. |
|
From: Philipp R. <pr...@pa...> - 2000-08-21 22:09:41
|
On Mon, Aug 21, 2000 at 02:01:59PM -0700, Linus Torvalds wrote: > On Mon, 21 Aug 2000, Philipp Rumpf wrote: > > On Mon, Aug 21, 2000 at 12:02:03PM -0700, Linus Torvalds wrote: > > 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. Possible. It's also possible people will go back to having many protocols, if only because it's just another few K of firmware ROM on the device side and the fibre connection is physically identical. > > I don't think "there aren't going to be a great many file in this directory" > > is really a good argument against creating a directory, except for the very > > special case that there would be no files at all in it. > > I think you're wrong. > > Logical naming and hierarchy are only helpers. If they lead to people > finding the files more quickly and understanding them better, they are > doing their job. > If hierarchy leads to having to look more places, think about it more, and According to my proposal, we would end up having all network drivers in drivers/*/net/*. Currently we have arch/*/drivers/net/*, drivers/net/*, drivers/net/*/*, and drivers/*/net/*. > just more work, that hierarchy is BAD. It doesn't matter if it is logical > or not. It sucks. It just ends up being in your way. I agree with the general statement. I also think it applies to the current hierarchy more strongly than to the proposed new hierarchy. The current hierarchy isn't logical, but it also doesn't give you a low number of places to look in for drivers. My opinion about the next point should be pretty obvious, and I do believe it is getting in the way of people actually trying to read some drivers. > We could create a subdirectory for each driver. In some cases we _do_ > that (tulip and ide come to mind). But in the end, it should be done only > when it clarifies things, not just because somebody thinks it "ought" to > be that way. Just to avoid misunderstandments, I never proposed creating a directory for each driver. I agree it's a bad idea. > And "there aren't going to be many files in this directory" is an argument > against it. It means that the directory doesn't end up clarifying things > very much at all. I would say drivers/s390/net and drivers/s390/misc are good directories. They clarify things. Most people just couldn't care less for them, and those people can safely ignore all of drivers/s390. Most people don't care for sbus, acorn, or sgi, either. some weird embedded people don't care about PCI. Most people don't care about weird embedded people's devices. Philipp |
|
From: Linus T. <tor...@tr...> - 2000-08-21 22:32:02
|
On Mon, 21 Aug 2000, Philipp Rumpf wrote: > > > If hierarchy leads to having to look more places, think about it more, and > > According to my proposal, we would end up having all network drivers in > drivers/*/net/*. But even that isn't enough, as shown by the tulip driver: basically even the regular PC drivers are available in so many different setups that you'd still want sub-hierarchies. (drivers/pc/ would end up being about 99% of the drivers, with the rest being just smatterings here and there). > I would say drivers/s390/net and drivers/s390/misc are good directories. I would not disagree entirely. At the same time, there would be advantages to arch/s390/drivers too. Especially if most people aren't that interested in them - keep them out of the way. Keeping them out of the way is bad at times (ie those times when changes are made that affect everybody). But at other times it would be exactly what you want. Not polluting the namespace with stuff you don't want or need is nice. What I'm saying is that it's not a case of "this is the right solution". I think drivers/input _is_ a good solution. I think it sucks as a solution if it implies moving all the drivers that need it into the same place, but I think it's potentially the right answer if it's localized to the "core input handling routines" and people see it that way (kind of the same way drivers/pci works - not all pci drivers are there, but it is a good way to partition the _generic_ issues about PCI somewhere which is neutral wrt what the driver actually ends up doing). But other issues, like how to move things around.. I'm not going to make that choice as long as it's not the "obviously right one". As long as it's not clear what the best choice is, the best bet is always "do as little as possible, and nothing more". Linus |
|
From: Vojtech P. <vo...@su...> - 2000-08-21 23:21:31
|
On Mon, Aug 21, 2000 at 02:01:59PM -0700, Linus Torvalds wrote: > And "there aren't going to be many files in this directory" is an argument > against it. It means that the directory doesn't end up clarifying things > very much at all. I have 63 .c files in the drivers/input directory in the linux-console CVS. Some more will be added later. Is that enough? IMHO it groups together stuff that belongs together. But opinions vary. -- Vojtech Pavlik SuSE Labs |
|
From: Linus T. <tor...@tr...> - 2000-08-22 03:48:29
|
On Tue, 22 Aug 2000, Vojtech Pavlik wrote: > On Mon, Aug 21, 2000 at 02:01:59PM -0700, Linus Torvalds wrote: > > > And "there aren't going to be many files in this directory" is an argument > > against it. It means that the directory doesn't end up clarifying things > > very much at all. > > I have 63 .c files in the drivers/input directory in the linux-console CVS. > Some more will be added later. Is that enough? IMHO it groups together > stuff that belongs together. But opinions vary. Hey, move a few drivers from drivers/scsi there too, and you'll have a few hundred .c files there. If you didn't guess already, I disagree strongly with people moving USB drivers around. I don't see the logic in it, AT ALL. The USB drivers use "kmalloc()" to allocate memory. Does that mean that they are part of memory management, and we should move them to mm/drivers? Obviously not. Nobody would be stupid enough to really argue that. Yet people seem to argue that because some USB drivers use features offered by the input layer, they should be "input drivers". Not so. Linus |
|
From: <R.E...@Bi...> - 2000-08-22 06:48:07
|
Linus Torvalds wrote: > I would not be unhappy to have separate drivers for different chipsets, > and even if you want to have the same driver for a 16450 and a 16550 (they > _are_ quite close, after all), it's not clear that it makes sense to do > the same thing for the multiport things etc. Linus, when I got my first "speed4" card, (PCI, single chip quad uart based card), I just typed a few setserial commands, and had the card running. It is the 16550 driver that handles this chip. 8250, 16450 16550 are all ISA. Now we have a chip that's two levels away (PCI, quad) getting handled by the same driver. It really would help reduce bugs if there were more shared code. If you split drivers, the number of users will drop. So less bugs get found. 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 ******** |
|
From: Eric S. R. <es...@th...> - 2000-08-22 07:03:02
|
Rogier Wolff <R.E...@Bi...>: > It really would help reduce bugs if there were more shared code. > > If you split drivers, the number of users will drop. So less bugs get > found. Linus, I think this is an excellent point and one you should consider. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "If I must write the truth, I am disposed to avoid every assembly of bishops; for of no synod have I seen a profitable end, but rather an addition to than a diminution of evils; for the love of strife and the thirst for superiority are beyond the power of words to express." -- Father Gregory Nazianzen, 381 AD |
|
From: David W. <dw...@in...> - 2000-08-22 10:39:40
|
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 |
|
From: <R.E...@Bi...> - 2000-08-22 12:17:39
|
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 ******** |
|
From: Bjorn W. <bj...@sp...> - 2000-08-22 13:04:49
|
[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 |
|
From: <R.E...@Bi...> - 2000-08-22 13:48:07
|
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 ******** |
|
From: Theodore Ts'o <ty...@va...> - 2000-08-22 15:32:06
|
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 |
|
From: Linus T. <tor...@tr...> - 2000-08-22 16:24:01
|
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 |
|
From: Bjorn W. <bj...@sp...> - 2000-08-22 21:03:53
|
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 |
|
From: Alan C. <al...@lx...> - 2000-08-23 10:14:21
|
> 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 |
|
From: Theodore Ts'o <ty...@va...> - 2000-08-23 16:22:33
|
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 |
|
From: Vojtech P. <vo...@su...> - 2000-08-22 12:39:40
|
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 |
|
From: Philipp R. <pr...@pa...> - 2000-08-22 11:00:45
|
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 |
|
From: Jeff R. <ra...@bi...> - 2000-08-25 17:41:57
|
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..."
|
|
From: Russell K. <rm...@ar...> - 2000-08-21 20:02:45
|
Linus Torvalds writes: > The last should probably be arch/<xxx>/drivers, but the other ones are > either sensible (tons of bus-independent drivers) or conceptual UNIX > things (char vs block). This is where I start rolling around all over the floor laughing at various people... Under pressure from others, I moved all the drivers I used to have in arch/arm/drivers in the 2.0 trees into the generic drivers/* directories. It now seems that these "others" were wrong for the ARM specific drivers. I do now agree that all drivers should be placed in the drivers subdirectory, and not anywhere under arch/*/drivers since, when some people go around checking net device drivers, they ONLY look in drivers/net, and nowhere else. I'm even considering moving drivers/acorn/net to drivers/net/acorn (and similarly for the others) so that when changes do occur, these drivers also get a look in. However, having said that, I think drivers/media is a good idea, but do we have enough drivers or separation to warrant drivers/media/radio and drivers/media/video? I'm willing to pick this change up btw, if no one objects. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rm...@ar... --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | |
|
From: Linus T. <tor...@tr...> - 2000-08-21 20:13:13
|
On Mon, 21 Aug 2000, Russell King wrote: > > I do now agree that all drivers should be placed in the drivers > subdirectory, and not anywhere under arch/*/drivers since, when some > people go around checking net device drivers, they ONLY look in > drivers/net, and nowhere else. That's a fairly good point - the fact that even if you came up with the perfect hierarchy that explained where everything is sanely, it would suck simply because people don't think that way. In the end, we just have to balance the "everything in one place so that it is easy to find" with "uhhuh, that 'ls' output is just too confusing, and I can't seem to find my driver any more". Linus |
|
From: Vojtech P. <vo...@su...> - 2000-08-20 20:34:24
|
On Sun, Aug 20, 2000 at 09:12:44AM -0400, jsi...@ne... wrote: > > > Any reason you don`t accept this patch? To me it looks like a obvious > > and clean solution and it would greatly simplify my use of the input > > infrastructure in my new driver for ADB input devices. Otherwise ugly > > Config.in and Makefile hacks will be necessary to select this driver in > > the drivers/usb directory if only CONFIG_ADB is set (same problem that > > already happens to the people trying to use joysticks without CONFIG_USB > > set). > > If you have any reason to reject that change (which essentially is > > just a move of files) for 2.4.0, please tell us. > > Yes it was rejected because of the massive moving of files. Linus feels > that ugly Config.in and Makefile hacks will do for now. By the way, I haven't found a way how do do it without the move with just the ugly tricks even. Perhaps there is one, but I guess it's beyond my limit of ugliness. -- Vojtech Pavlik SuSE Labs |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X