* [RFC] possible removal of omap-serial @ 2014-03-20 23:52 Felipe Balbi 2014-03-21 0:04 ` Alan Cox 2014-03-21 0:12 ` Greg KH 0 siblings, 2 replies; 11+ messages in thread From: Felipe Balbi @ 2014-03-20 23:52 UTC (permalink / raw) To: linux-arm-kernel Hi folks, I've been toying with the idea of removing drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an ungly copy of 8250 driver. The original concern was wrt suspend/resume but I think it'd be a far better approach to implement runtime PM in 8250 and write a rather small 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the OMAP-specific details out of the way. The question I have is: omap-serial.c calls the serial devnodes ttyO\d, instead of ttyS\d so removing omap-serial.c would have a direct impact in userland. I wonder if it's an acceptable "regression" considering we'd be able to reuse 8250 gaining proper Flow Control support, proper DMA support, years and years of bug-fixes, etc. What do you guys say ? -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/277e2096/attachment.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-20 23:52 [RFC] possible removal of omap-serial Felipe Balbi @ 2014-03-21 0:04 ` Alan Cox 2014-03-21 0:12 ` Greg KH 1 sibling, 0 replies; 11+ messages in thread From: Alan Cox @ 2014-03-21 0:04 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2014-03-20 at 18:52 -0500, Felipe Balbi wrote: > Hi folks, > > I've been toying with the idea of removing > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > ungly copy of 8250 driver. > > The original concern was wrt suspend/resume but I think it'd be a far > better approach to implement runtime PM in 8250 and write a rather small > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > OMAP-specific details out of the way. > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > instead of ttyS\d so removing omap-serial.c would have a direct impact > in userland. I wonder if it's an acceptable "regression" considering > we'd be able to reuse 8250 gaining proper Flow Control support, proper > DMA support, years and years of bug-fixes, etc. > > What do you guys say ? I think it would be better even if we have to support calling it ttyO%d somehow. Alan ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-20 23:52 [RFC] possible removal of omap-serial Felipe Balbi 2014-03-21 0:04 ` Alan Cox @ 2014-03-21 0:12 ` Greg KH 2014-03-21 1:35 ` Felipe Balbi 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2014-03-21 0:12 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: > Hi folks, > > I've been toying with the idea of removing > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > ungly copy of 8250 driver. > > The original concern was wrt suspend/resume but I think it'd be a far > better approach to implement runtime PM in 8250 and write a rather small > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > OMAP-specific details out of the way. > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > instead of ttyS\d so removing omap-serial.c would have a direct impact > in userland. I wonder if it's an acceptable "regression" considering > we'd be able to reuse 8250 gaining proper Flow Control support, proper > DMA support, years and years of bug-fixes, etc. Breaking device node names is a contentious issue for serial ports, I don't think you can do that :( ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 0:12 ` Greg KH @ 2014-03-21 1:35 ` Felipe Balbi 2014-03-21 1:37 ` Felipe Balbi 0 siblings, 1 reply; 11+ messages in thread From: Felipe Balbi @ 2014-03-21 1:35 UTC (permalink / raw) To: linux-arm-kernel Hi, On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote: > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: > > Hi folks, > > > > I've been toying with the idea of removing > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > > ungly copy of 8250 driver. > > > > The original concern was wrt suspend/resume but I think it'd be a far > > better approach to implement runtime PM in 8250 and write a rather small > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > > OMAP-specific details out of the way. > > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > > instead of ttyS\d so removing omap-serial.c would have a direct impact > > in userland. I wonder if it's an acceptable "regression" considering > > we'd be able to reuse 8250 gaining proper Flow Control support, proper > > DMA support, years and years of bug-fixes, etc. > > Breaking device node names is a contentious issue for serial ports, I > don't think you can do that :( would an upstream udev rule creating a symbolic link from ttyO to ttyS be enough ? I didn't test this yet but I guess this is enough (?) KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS" -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/de2b9cbe/attachment-0001.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 1:35 ` Felipe Balbi @ 2014-03-21 1:37 ` Felipe Balbi 2014-03-21 2:36 ` Greg KH 0 siblings, 1 reply; 11+ messages in thread From: Felipe Balbi @ 2014-03-21 1:37 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote: > Hi, > > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote: > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: > > > Hi folks, > > > > > > I've been toying with the idea of removing > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > > > ungly copy of 8250 driver. > > > > > > The original concern was wrt suspend/resume but I think it'd be a far > > > better approach to implement runtime PM in 8250 and write a rather small > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > > > OMAP-specific details out of the way. > > > > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > > > instead of ttyS\d so removing omap-serial.c would have a direct impact > > > in userland. I wonder if it's an acceptable "regression" considering > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper > > > DMA support, years and years of bug-fixes, etc. > > > > Breaking device node names is a contentious issue for serial ports, I > > don't think you can do that :( > > would an upstream udev rule creating a symbolic link from ttyO to ttyS > be enough ? > > I didn't test this yet but I guess this is enough (?) > > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS" or actually it should be to other way around, ttyS would be the real device: KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO" -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/f8cee27f/attachment.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 1:37 ` Felipe Balbi @ 2014-03-21 2:36 ` Greg KH 2014-03-21 2:45 ` Robert Nelson 0 siblings, 1 reply; 11+ messages in thread From: Greg KH @ 2014-03-21 2:36 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote: > On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote: > > Hi, > > > > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote: > > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: > > > > Hi folks, > > > > > > > > I've been toying with the idea of removing > > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > > > > ungly copy of 8250 driver. > > > > > > > > The original concern was wrt suspend/resume but I think it'd be a far > > > > better approach to implement runtime PM in 8250 and write a rather small > > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > > > > OMAP-specific details out of the way. > > > > > > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > > > > instead of ttyS\d so removing omap-serial.c would have a direct impact > > > > in userland. I wonder if it's an acceptable "regression" considering > > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper > > > > DMA support, years and years of bug-fixes, etc. > > > > > > Breaking device node names is a contentious issue for serial ports, I > > > don't think you can do that :( > > > > would an upstream udev rule creating a symbolic link from ttyO to ttyS > > be enough ? > > > > I didn't test this yet but I guess this is enough (?) > > > > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS" > > or actually it should be to other way around, ttyS would be the real > device: > > KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO" As udev rules don't ship with the kernel, this might be tough to do :( Might be easier to make the 8250 driver handle different "names" like Alan said. greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 2:36 ` Greg KH @ 2014-03-21 2:45 ` Robert Nelson 2014-03-21 2:52 ` Felipe Balbi 0 siblings, 1 reply; 11+ messages in thread From: Robert Nelson @ 2014-03-21 2:45 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 20, 2014 at 9:36 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote: >> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote: >> > Hi, >> > >> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote: >> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: >> > > > Hi folks, >> > > > >> > > > I've been toying with the idea of removing >> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an >> > > > ungly copy of 8250 driver. >> > > > >> > > > The original concern was wrt suspend/resume but I think it'd be a far >> > > > better approach to implement runtime PM in 8250 and write a rather small >> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the >> > > > OMAP-specific details out of the way. >> > > > >> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, >> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact >> > > > in userland. I wonder if it's an acceptable "regression" considering >> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper >> > > > DMA support, years and years of bug-fixes, etc. >> > > >> > > Breaking device node names is a contentious issue for serial ports, I >> > > don't think you can do that :( >> > >> > would an upstream udev rule creating a symbolic link from ttyO to ttyS >> > be enough ? >> > >> > I didn't test this yet but I guess this is enough (?) >> > >> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS" >> >> or actually it should be to other way around, ttyS would be the real >> device: >> >> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO" > > As udev rules don't ship with the kernel, this might be tough to do :( > > Might be easier to make the 8250 driver handle different "names" like > Alan said. On the support side, I'm not looking forward to this for beagle/panda users. We've already converted them once from ttySx -> ttyOx back in 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare... Regards, -- Robert Nelson http://www.rcn-ee.com/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 2:45 ` Robert Nelson @ 2014-03-21 2:52 ` Felipe Balbi 2014-03-21 17:10 ` Tony Lindgren 0 siblings, 1 reply; 11+ messages in thread From: Felipe Balbi @ 2014-03-21 2:52 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 20, 2014 at 09:45:42PM -0500, Robert Nelson wrote: > On Thu, Mar 20, 2014 at 9:36 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote: > >> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote: > >> > Hi, > >> > > >> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote: > >> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: > >> > > > Hi folks, > >> > > > > >> > > > I've been toying with the idea of removing > >> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > >> > > > ungly copy of 8250 driver. > >> > > > > >> > > > The original concern was wrt suspend/resume but I think it'd be a far > >> > > > better approach to implement runtime PM in 8250 and write a rather small > >> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > >> > > > OMAP-specific details out of the way. > >> > > > > >> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > >> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact > >> > > > in userland. I wonder if it's an acceptable "regression" considering > >> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper > >> > > > DMA support, years and years of bug-fixes, etc. > >> > > > >> > > Breaking device node names is a contentious issue for serial ports, I > >> > > don't think you can do that :( > >> > > >> > would an upstream udev rule creating a symbolic link from ttyO to ttyS > >> > be enough ? > >> > > >> > I didn't test this yet but I guess this is enough (?) > >> > > >> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS" > >> > >> or actually it should be to other way around, ttyS would be the real > >> device: > >> > >> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO" > > > > As udev rules don't ship with the kernel, this might be tough to do :( > > > > Might be easier to make the 8250 driver handle different "names" like > > Alan said. I'll see if I find a way to avoid that or at least see if we find any other way of creating a symlink... In any case, just switching back to 8250, even if just maintaining ttyO name, is already a big benefit. > On the support side, I'm not looking forward to this for beagle/panda > users. We've already converted them once from ttySx -> ttyOx back in > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare... that's exactly why we're talking about ways to maintain backwards compatibility here. But I'm more interested in finding a way to switch over to ttyS and have a symlink to ttyO, that way a simple debootstrap (or any other ARM distro minimal rootfs) would work out of the box, without any changes, just like in "normal" systems. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/c35bb0fa/attachment.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 2:52 ` Felipe Balbi @ 2014-03-21 17:10 ` Tony Lindgren 2014-03-21 17:36 ` Felipe Balbi 0 siblings, 1 reply; 11+ messages in thread From: Tony Lindgren @ 2014-03-21 17:10 UTC (permalink / raw) To: linux-arm-kernel * Felipe Balbi <balbi@ti.com> [140320 19:57]: > On Thu, Mar 20, 2014 at 09:45:42PM -0500, Robert Nelson wrote: > > On Thu, Mar 20, 2014 at 9:36 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > > On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote: > > >> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote: > > >> > Hi, > > >> > > > >> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote: > > >> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote: > > >> > > > Hi folks, > > >> > > > > > >> > > > I've been toying with the idea of removing > > >> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an > > >> > > > ungly copy of 8250 driver. > > >> > > > > > >> > > > The original concern was wrt suspend/resume but I think it'd be a far > > >> > > > better approach to implement runtime PM in 8250 and write a rather small > > >> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the > > >> > > > OMAP-specific details out of the way. > > >> > > > > > >> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d, > > >> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact > > >> > > > in userland. I wonder if it's an acceptable "regression" considering > > >> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper > > >> > > > DMA support, years and years of bug-fixes, etc. > > >> > > > > >> > > Breaking device node names is a contentious issue for serial ports, I > > >> > > don't think you can do that :( > > >> > > > >> > would an upstream udev rule creating a symbolic link from ttyO to ttyS > > >> > be enough ? > > >> > > > >> > I didn't test this yet but I guess this is enough (?) > > >> > > > >> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS" > > >> > > >> or actually it should be to other way around, ttyS would be the real > > >> device: > > >> > > >> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO" > > > > > > As udev rules don't ship with the kernel, this might be tough to do :( > > > > > > Might be easier to make the 8250 driver handle different "names" like > > > Alan said. > > I'll see if I find a way to avoid that or at least see if we find any > other way of creating a symlink... In any case, just switching back to > 8250, even if just maintaining ttyO name, is already a big benefit. > > > On the support side, I'm not looking forward to this for beagle/panda > > users. We've already converted them once from ttySx -> ttyOx back in > > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare... > > that's exactly why we're talking about ways to maintain backwards > compatibility here. But I'm more interested in finding a way to switch > over to ttyS and have a symlink to ttyO, that way a simple debootstrap > (or any other ARM distro minimal rootfs) would work out of the box, > without any changes, just like in "normal" systems. Yeah let's not break things. The symlink solution won't work for kernel console output so it needs to be dealt with some other way. It seems that the biggest amount of work is making existing 8250 support the missing features in a clean way and without breaking other platforms. Looks like 8250_dw.c has some pm_runtime_calls so obviously it's doable. Regards, Tony ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 17:10 ` Tony Lindgren @ 2014-03-21 17:36 ` Felipe Balbi 2014-03-21 17:44 ` Greg KH 0 siblings, 1 reply; 11+ messages in thread From: Felipe Balbi @ 2014-03-21 17:36 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Mar 21, 2014 at 10:10:30AM -0700, Tony Lindgren wrote: > > > On the support side, I'm not looking forward to this for beagle/panda > > > users. We've already converted them once from ttySx -> ttyOx back in > > > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare... > > > > that's exactly why we're talking about ways to maintain backwards > > compatibility here. But I'm more interested in finding a way to switch > > over to ttyS and have a symlink to ttyO, that way a simple debootstrap > > (or any other ARM distro minimal rootfs) would work out of the box, > > without any changes, just like in "normal" systems. > > Yeah let's not break things. The symlink solution won't work for kernel again. Let's not break things again. > console output so it needs to be dealt with some other way. it would if kernel itself would create the symlink, but that might not be doable in a clean way. > It seems that the biggest amount of work is making existing 8250 > support the missing features in a clean way and without breaking > other platforms. Looks like 8250_dw.c has some pm_runtime_calls so > obviously it's doable. right -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/2335bfe4/attachment.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial 2014-03-21 17:36 ` Felipe Balbi @ 2014-03-21 17:44 ` Greg KH 0 siblings, 0 replies; 11+ messages in thread From: Greg KH @ 2014-03-21 17:44 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 21, 2014 at 12:36:53PM -0500, Felipe Balbi wrote: > Hi, > > On Fri, Mar 21, 2014 at 10:10:30AM -0700, Tony Lindgren wrote: > > > > On the support side, I'm not looking forward to this for beagle/panda > > > > users. We've already converted them once from ttySx -> ttyOx back in > > > > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare... > > > > > > that's exactly why we're talking about ways to maintain backwards > > > compatibility here. But I'm more interested in finding a way to switch > > > over to ttyS and have a symlink to ttyO, that way a simple debootstrap > > > (or any other ARM distro minimal rootfs) would work out of the box, > > > without any changes, just like in "normal" systems. > > > > Yeah let's not break things. The symlink solution won't work for kernel > > again. Let's not break things again. > > > console output so it needs to be dealt with some other way. > > it would if kernel itself would create the symlink, but that might not > be doable in a clean way. The kernel isn't going to create the symlink, sorry, no. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-03-21 17:44 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-20 23:52 [RFC] possible removal of omap-serial Felipe Balbi 2014-03-21 0:04 ` Alan Cox 2014-03-21 0:12 ` Greg KH 2014-03-21 1:35 ` Felipe Balbi 2014-03-21 1:37 ` Felipe Balbi 2014-03-21 2:36 ` Greg KH 2014-03-21 2:45 ` Robert Nelson 2014-03-21 2:52 ` Felipe Balbi 2014-03-21 17:10 ` Tony Lindgren 2014-03-21 17:36 ` Felipe Balbi 2014-03-21 17:44 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).