diff for duplicates of <3D457FA8.DFACC4FF@gmx.at> diff --git a/a/1.txt b/N1/1.txt index fa331c1..3a56205 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,16 +1,15 @@ - Ad "setserial API": Please use /proc/serialdev (or similar), *NOT* a `/dev' entry !! This is typical `/proc'-FS stuff ! -(See SCSI: echo "scsi add-single-device 0 0 4 0" > /proc/scsi/scsi +(See SCSI: echo "scsi add-single-device 0 0 4 0" > /proc/scsi/scsi !!!) Christoph P. Russell King wrote: -> +> > On Mon, Jul 29, 2002 at 07:44:08AM -0700, Tom Rini wrote: > > On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote: > > > Unless ppc and others are willing to put up with major breakage when I @@ -18,48 +17,48 @@ Russell King wrote: > > > this area welcome. > > > > Well, what changes do you have in mind? -> +> > Firstly, apologies to Tom for turning this into a general discussion > mail. At the request of Tom, this message is also CC:'d to the PPC > devel lists. -> +> > There's quite a lot in here, so please, when replying edit out stuff > your not replying to. Thanks. -> +> > 1. Serial port initialisation > ----------------------------- -> +> > Firstly, one thing to bear in mind here is that, as Alan says "be nice > to make sure it was much earlier". I guess Alan's right, so we can get > oopsen out of the the kernel relatively easily, even when we're using > framebuffer consoles. -> +> > I'm sure Alan will enlighten us with his specific reasons if required. -> +> > There have been several suggestions around on how to fix this table: -> +> > a. architectures provide a sub-module to 8250.c which contains the > per-port details, rather than a table in serial.h. This would > ideally mean removing serial.h completely. The relevant object > would be linked into 8250.c when 8250.c is built as a module. -> +> > b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends > each containing the parameters for the specific cards and handle it > as above. -> +> > c. make it the responsibility of user space to tell the kernel about > many serial ports, and leave just the ones necessary for serial > console in the kernel. (see issue 2 below) -> +> > d. we keep serial.h, make it 8250-compatible ports only, and change > CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT > This is the simplest and least likely to break other code. On the > other hand, we end up hauling the ISA table and struct old_serial_port > into 2.6. -> +> > 2. setserial API > ---------------- -> +> > This is actually tied closely into another issue; I'd like to get rid > of this silly idea where we're able to open serial ports that don't > exist (ie, their UART is "unknown"). This behaviour appears to be for @@ -67,70 +66,72 @@ Russell King wrote: > interrupt levels, etc. Removing this facility would require a new API > for such things. The best suggestion made so far is to do something > like: -> +> > # echo "add 0x2e8,3,autoconfig" >/dev/serialctl > # echo "remove 0x2e8" >/dev/serialctl -> +> > (or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists) -> +> > where we have "add ioport,irq,flags" and "remove ioport" (note that > mmio ports aren't covered here since they require ioremap games which > tends to be card specific!) -> +> > Why make this change? Well, we have quite a lot of baggage being > dragged around to support configuration of an open port and being > able to open a non-existent port. I'd really like to get rid of > this excess baggage. -> +> > 3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc > --------------------------------------------------------- -> +> > All the above are serial ports of various types. It has been expressed > several times that people would like to see all of them appear as > /dev/ttyS* (indeed, there was an, erm, rather heated discussion about > it a couple of years ago.) I'm going to be neutral on this point > here. -> +> > There are several issues surrounding this: -> +> > a. The serial core.c is very almost capable of handling this abstraction, > with one exception - a registered port can only be in one group at > one time. This restriction is brought about because of the way the > tty layer handles its tty ports. -> +> > (Handling dual registrations in two different majors gets _really_ > messy - eg, you two built-in 16550A ports and two SA1100 ports > taking up ttyS0 to ttyS3. You then add a 16550A PCMCIA modem, > which becomes ttyS4. Oh, and the SA1100 ports are also appearing > as ttySA0 and ttySA1. _really_ messy. No thanks.) -> +> > b. serial consoles. Each hardware driver handles its serial consoles > by itself, and if you have two or more hardware drivers built in > with serial console support, you need to be able to tell them apart > with the console= kernel parameter. -> +> > Again, this could be solvable if we have one "ttyS" view of everything > (core.c would then be responsible for registering the console with > printk.c and passing the various methods off to the relevant > hardware). -> +> > c. People with many serial ports. We _could_ change the device number > allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc > device numbers so we end up with the same number of port slots > available for those with many many serial ports in their machines. -> +> > -- > Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux > http://www.arm.linux.org.uk/personal/aboutme.html +> - +> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in +> the body of a message to majordomo@vger.kernel.org +> More majordomo info at http://vger.kernel.org/majordomo-info.html +> Please read the FAQ at http://www.tux.org/lkml/ > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --- +-- ------------------------------------------------------- private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at - - -** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ diff --git a/a/content_digest b/N1/content_digest index 7eef451..2927f16 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,26 +3,25 @@ "ref\020020729144408.GA11206@opus.bloom.county\0" "ref\020020729181702.E25451@flint.arm.linux.org.uk\0" "From\0Christoph Plattner <christoph.plattner@gmx.at>\0" - "Subject\0Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)\0" + "Subject\0Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)\0" "Date\0Mon, 29 Jul 2002 19:47:20 +0200\0" "To\0Russell King <rmk@arm.linux.org.uk>\0" "Cc\0linux-kernel@vger.kernel.org" " linuxppc-dev@lists.linuxppc.org\0" "\00:1\0" "b\0" - "\n" "Ad \"setserial API\":\n" "\n" "Please use /proc/serialdev (or similar), *NOT* a `/dev' entry !!\n" "This is typical `/proc'-FS stuff !\n" - "(See SCSI: echo \"scsi add-single-device 0 0 4 0\" > /proc/scsi/scsi\n" + "(See SCSI: echo \"scsi add-single-device 0 0 4 0\" > /proc/scsi/scsi \n" "!!!)\n" "\n" "Christoph P.\n" "\n" "\n" "Russell King wrote:\n" - ">\n" + "> \n" "> On Mon, Jul 29, 2002 at 07:44:08AM -0700, Tom Rini wrote:\n" "> > On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:\n" "> > > Unless ppc and others are willing to put up with major breakage when I\n" @@ -30,48 +29,48 @@ "> > > this area welcome.\n" "> >\n" "> > Well, what changes do you have in mind?\n" - ">\n" + "> \n" "> Firstly, apologies to Tom for turning this into a general discussion\n" "> mail. At the request of Tom, this message is also CC:'d to the PPC\n" "> devel lists.\n" - ">\n" + "> \n" "> There's quite a lot in here, so please, when replying edit out stuff\n" "> your not replying to. Thanks.\n" - ">\n" + "> \n" "> 1. Serial port initialisation\n" "> -----------------------------\n" - ">\n" + "> \n" "> Firstly, one thing to bear in mind here is that, as Alan says \"be nice\n" "> to make sure it was much earlier\". I guess Alan's right, so we can get\n" "> oopsen out of the the kernel relatively easily, even when we're using\n" "> framebuffer consoles.\n" - ">\n" + "> \n" "> I'm sure Alan will enlighten us with his specific reasons if required.\n" - ">\n" + "> \n" "> There have been several suggestions around on how to fix this table:\n" - ">\n" + "> \n" "> a. architectures provide a sub-module to 8250.c which contains the\n" "> per-port details, rather than a table in serial.h. This would\n" "> ideally mean removing serial.h completely. The relevant object\n" "> would be linked into 8250.c when 8250.c is built as a module.\n" - ">\n" + "> \n" "> b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends\n" "> each containing the parameters for the specific cards and handle it\n" "> as above.\n" - ">\n" + "> \n" "> c. make it the responsibility of user space to tell the kernel about\n" "> many serial ports, and leave just the ones necessary for serial\n" "> console in the kernel. (see issue 2 below)\n" - ">\n" + "> \n" "> d. we keep serial.h, make it 8250-compatible ports only, and change\n" "> CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT\n" "> This is the simplest and least likely to break other code. On the\n" "> other hand, we end up hauling the ISA table and struct old_serial_port\n" "> into 2.6.\n" - ">\n" + "> \n" "> 2. setserial API\n" "> ----------------\n" - ">\n" + "> \n" "> This is actually tied closely into another issue; I'd like to get rid\n" "> of this silly idea where we're able to open serial ports that don't\n" "> exist (ie, their UART is \"unknown\"). This behaviour appears to be for\n" @@ -79,72 +78,74 @@ "> interrupt levels, etc. Removing this facility would require a new API\n" "> for such things. The best suggestion made so far is to do something\n" "> like:\n" - ">\n" + "> \n" "> # echo \"add 0x2e8,3,autoconfig\" >/dev/serialctl\n" "> # echo \"remove 0x2e8\" >/dev/serialctl\n" - ">\n" + "> \n" "> (or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)\n" - ">\n" + "> \n" "> where we have \"add ioport,irq,flags\" and \"remove ioport\" (note that\n" "> mmio ports aren't covered here since they require ioremap games which\n" "> tends to be card specific!)\n" - ">\n" + "> \n" "> Why make this change? Well, we have quite a lot of baggage being\n" "> dragged around to support configuration of an open port and being\n" "> able to open a non-existent port. I'd really like to get rid of\n" "> this excess baggage.\n" - ">\n" + "> \n" "> 3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc\n" "> ---------------------------------------------------------\n" - ">\n" + "> \n" "> All the above are serial ports of various types. It has been expressed\n" "> several times that people would like to see all of them appear as\n" "> /dev/ttyS* (indeed, there was an, erm, rather heated discussion about\n" "> it a couple of years ago.) I'm going to be neutral on this point\n" "> here.\n" - ">\n" + "> \n" "> There are several issues surrounding this:\n" - ">\n" + "> \n" "> a. The serial core.c is very almost capable of handling this abstraction,\n" "> with one exception - a registered port can only be in one group at\n" "> one time. This restriction is brought about because of the way the\n" "> tty layer handles its tty ports.\n" - ">\n" + "> \n" "> (Handling dual registrations in two different majors gets _really_\n" "> messy - eg, you two built-in 16550A ports and two SA1100 ports\n" "> taking up ttyS0 to ttyS3. You then add a 16550A PCMCIA modem,\n" "> which becomes ttyS4. Oh, and the SA1100 ports are also appearing\n" "> as ttySA0 and ttySA1. _really_ messy. No thanks.)\n" - ">\n" + "> \n" "> b. serial consoles. Each hardware driver handles its serial consoles\n" "> by itself, and if you have two or more hardware drivers built in\n" "> with serial console support, you need to be able to tell them apart\n" "> with the console= kernel parameter.\n" - ">\n" + "> \n" "> Again, this could be solvable if we have one \"ttyS\" view of everything\n" "> (core.c would then be responsible for registering the console with\n" "> printk.c and passing the various methods off to the relevant\n" "> hardware).\n" - ">\n" + "> \n" "> c. People with many serial ports. We _could_ change the device number\n" "> allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc\n" "> device numbers so we end up with the same number of port slots\n" "> available for those with many many serial ports in their machines.\n" - ">\n" + "> \n" "> --\n" "> Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux\n" "> http://www.arm.linux.org.uk/personal/aboutme.html\n" + "> -\n" + "> To unsubscribe from this list: send the line \"unsubscribe linux-kernel\" in\n" + "> the body of a message to majordomo@vger.kernel.org\n" + "> More majordomo info at http://vger.kernel.org/majordomo-info.html\n" + "> Please read the FAQ at http://www.tux.org/lkml/\n" "> _______________________________________________\n" "> parisc-linux mailing list\n" "> parisc-linux@lists.parisc-linux.org\n" "> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux\n" "\n" - "--\n" + "-- \n" "-------------------------------------------------------\n" "private:\tchristoph.plattner@gmx.at\n" - "company:\tchristoph.plattner@alcatel.at\n" - "\n" - "\n" - ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ + "company:\tchristoph.plattner@alcatel.at" -d15aa3962d061549333fb0c88575e0fdb5d8f8626c38fe012fd8b49c0da2550b +1f317208f3904cd5a5ceac2ec566447599e9af16160ea64d2e3c3eb54dfd4f81
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.