netdev - Re: Driver for Solos PCI ADSL2+ card.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 26 Dec 2008 12:44:23 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: Driver for Solos PCI ADSL2+ card.

On Fri, 2008-12-26 at 01:27 -0800, David Miller wrote:
> Applied, but I don't need to tell you that this driver needs
> some work :)

Thanks. We'll be continuing to clean the driver up -- I have a card of
my own now, and should soon have a spare line to play with it without
having to disrupt my connectivity. One the way home from LCA I'll be
dropping in to Melbourne to see Traverse for a few days, and we should
get DMA working then.

One thing I'm not sure how to handle is the attributes. Currently we
expose a 'console' attribute file in sysfs. Reading parameters is done
by sending text to that:
	echo -en $$\\nParameterName\\n > /sys/.../console
	cat /sys/.../console

...and parameters are written by sending three lines of test:
	echo -en $$\\nParameterName\\nValue\\n > /sys/.../console
	cat /sys/.../console # to check for error

Currently, the kernel doesn't look at the request ID at all, and a
userspace program reading back from the file will receive _any_
responses and discard the ones it doesn't want.

We'll have to handle that properly, and we want to make the driver deal
with certain parameters for itself too -- like line speed and sync
status, which should be represented to the ATM layer.

I'm a little dubious about just exposing _all_ the parameters as
separate attribute files in sysfs though, because there are over 300 of
them. Maybe we could expose the _common_ ones like that, and have some
other interface which lets the user access others as required... but I
don't have strong opinions about how that latter interface should look.

One option is a character device which looks similar to the existing
interface. Or an ioctl, perhaps.

Another option is to let the user create attribute files in sysfs
dynamically, perhaps by echoing the desired parameter name to another
sysfs file.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html