| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1264161402-4669-1-git-send-email-kirr@mns.spb.ru>
Date: Fri, 22 Jan 2010 14:56:42 +0300
From: Kirill Smelkov <kirr@....spb.ru>
To: linux-kernel@...r.kernel.org
Cc: Kirill Smelkov <kirr@....spb.ru>, Jiri Slaby <jirislaby@...il.com>,
Alan Cox <alan@...ux.intel.com>,
Peter Botha <peterb@...dcircle.co.za>,
Denis Vlasenko <vda@...ort.com.ua>
Subject: [RFC PATCH] mxser: make /dev/ttyMI<n> namespace contiguous
Recently I've been beaten by the difference of how /dev/ttyMI* entries
are created for two cases:
a) two CP-114 cards (each with 4 ports), and
b) one CP-118 card (with 8 ports on board)
compare:
CP114+CP114 CP118
ttyMI0 ttyMI0
ttyMI1 ttyMI1
ttyMI2 ttyMI2
ttyMI3 ttyMI3
ttyMI8 ttyMI4
ttyMI9 ttyMI5
ttyMI10 ttyMI6
ttyMI11 ttyMI7
i.e. in case of 8-ports board, we have contigous /dev entries for 8
serial ports, but in case of two 4-ports board, there is a hole between
4th and 5th ports.
As I see it, the reason Moxa did things this way, is for userspace to
have a simple rule to know /dev entry for n'th port on m'th board easily
-- they always reserve 8 /dev entries for each board
(MXSER_PORTS_PER_BOARD) and the rule is 8*m+n.
However in my situation, this creates confusion -- when my system
starts, I'd like to know /dev entries for n'th serial port and bind
programs to appropriate ports and pretune config files for such
programs. Regardles of how those 8 ports are made - with one CP118
card, or with 2 CP114 cards.
Yes, on system startup, one could always create appropriate com-port
mapping, which will contigously enumerate ports, e.g. something like
this:
cd /dev/
n=0
for port in `ls ttyMI* | sort --key=1.6 -n`; do
ln -s $port com${n}
n=$(($n+1))
done
and then use /dev/com<n>, but is it the right way?
Maybe let's teach mxser to create continous /dev entries in the first
place?
The problem is in mxser_ioctl_special though. For MOXA_CHKPORTENABLE,
MOXA_GETMSTATUS and MOXA_ASPP_MOX_EXT the assumed layout is always 8
ports per board, and so userspace could get confused, if say
CHKPORTENABLE reports 1st port on 2nd board is present, but
open("/dev/ttyMI8") fails.
Although are these ioctls ever used? I've downloaded moxa drivers and
tools (driv_linux_smart_v1.14_build_09061611.tgz) and yes, their tools
use special ioctls, but anyway, the tools still use /dev/ttyM instead of
/dev/ttyMI, and e.g. GETMSTATUS is used on /dev/mxser only, so I'd say
this userspace user is ouuuuut of date.
So would be it an ABI breakage to kill these special ioctls, or change
them in some meaningful way to make /dev/ttyMI<n> namespace continous?
I'm not sure on this - that's why the patch is marked as RFC.
Please advice, and thanks beforehand,
Kirill
Cc: Jiri Slaby <jirislaby@...il.com>
Cc: Alan Cox <alan@...ux.intel.com>
Cc: Peter Botha <peterb@...dcircle.co.za>
Cc: Denis Vlasenko <vda@...ort.com.ua>
Signed-off-by: Kirill Smelkov <kirr@....spb.ru>
---
drivers/char/mxser.c | 31 ++++++++++++++++++++++++-------
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/char/mxser.c b/drivers/char/mxser.c
index 3d92306..21028b5 100644
--- a/drivers/char/mxser.c
+++ b/drivers/char/mxser.c
@@ -1002,13 +1002,27 @@ static int mxser_open(struct tty_struct *tty, struct file *filp)
{
struct mxser_port *info;
int line;
+ unsigned int i, nport;
+ struct mxser_board *board=NULL;
line = tty->index;
if (line == MXSER_PORTS)
return 0;
if (line < 0 || line > MXSER_PORTS)
return -ENODEV;
- info = &mxser_boards[line / MXSER_PORTS_PER_BOARD].ports[line % MXSER_PORTS_PER_BOARD];
+
+ for (nport = 0, i = 0; i < MXSER_BOARDS; i++)
+ if (line < nport + mxser_boards[i].info->nports) {
+ board = &mxser_boards[i];
+ break;
+ }
+ else
+ nport += mxser_boards[i].info->nports;
+
+ if (!board)
+ return -ENODEV;
+
+ info = &board->ports[line - nport];
if (!info->ioaddr)
return -ENODEV;
@@ -2525,13 +2539,15 @@ static int __devinit mxser_probe(struct pci_dev *pdev,
{
#ifdef CONFIG_PCI
struct mxser_board *brd;
- unsigned int i, j;
+ unsigned int i, j, nport;
unsigned long ioaddress;
int retval = -EINVAL;
- for (i = 0; i < MXSER_BOARDS; i++)
+ for (nport = 0, i = 0; i < MXSER_BOARDS; i++)
if (mxser_boards[i].info == NULL)
break;
+ else
+ nport += mxser_boards[i].info->nports;
if (i >= MXSER_BOARDS) {
dev_err(&pdev->dev, "too many boards found (maximum %d), board "
@@ -2540,7 +2556,7 @@ static int __devinit mxser_probe(struct pci_dev *pdev,
}
brd = &mxser_boards[i];
- brd->idx = i * MXSER_PORTS_PER_BOARD;
+ brd->idx = nport;
dev_info(&pdev->dev, "found MOXA %s board (BusNo=%d, DevNo=%d)\n",
mxser_cards[ent->driver_data].name,
pdev->bus->number, PCI_SLOT(pdev->devfn));
@@ -2649,7 +2665,7 @@ static struct pci_driver mxser_driver = {
static int __init mxser_module_init(void)
{
struct mxser_board *brd;
- unsigned int b, i, m;
+ unsigned int b, i, m, nport;
int retval;
mxvar_sdriver = alloc_tty_driver(MXSER_PORTS + 1);
@@ -2681,7 +2697,7 @@ static int __init mxser_module_init(void)
}
/* Start finding ISA boards here */
- for (m = 0, b = 0; b < MXSER_BOARDS; b++) {
+ for (nport = 0, m = 0, b = 0; b < MXSER_BOARDS; b++) {
if (!ioaddr[b])
continue;
@@ -2701,10 +2717,11 @@ static int __init mxser_module_init(void)
continue;
}
- brd->idx = m * MXSER_PORTS_PER_BOARD;
+ brd->idx = nport;
for (i = 0; i < brd->info->nports; i++)
tty_register_device(mxvar_sdriver, brd->idx + i, NULL);
+ nport += brd->info->nports;
m++;
}
--
1.6.6.1.394.gdedc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists