netdev - Re: [PATCH net-next-2.6] can: add slcan driver for serial/USB-serial CAN adapters

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4CF52911.6030900@hartkopp.net>
Date:	Tue, 30 Nov 2010 17:40:49 +0100
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	SocketCAN Core Mailing List <socketcan-core@...ts.berlios.de>
Subject: Re: [PATCH net-next-2.6] can: add slcan driver for serial/USB-serial
 CAN adapters

On 30.11.2010 00:37, Alan Cox wrote:
> On Mon, 29 Nov 2010 21:30:45 +0100
> Oliver Hartkopp <socketcan@...tkopp.net> wrote:
> 
>> This patch adds support for serial/USB-serial CAN adapters implementing the
>> LAWICEL ASCII protocol for CAN frame transport over serial lines.
>>
>> The driver implements the SLCAN line discipline and is heavily based on the
>> slip.c driver. Therefore the code style remains similar to slip.c to be able
>> to apply changes of the SLIP driver to the SLCAN driver easily.
> 
> It looks almost identical. Would it not be better to either extract the
> common code or put slip and slcann together as one, otherwise changes
> will always get missed as they have to be done twice ?
> 
> How hard would it be to make the encap/decap pointers that can be
> set to cleanly abstract both ?

My first approach was indeed to try to integrate the slcan ldisc into slip.
But due to the higher complexity with dynamic memory for the buffers, the
multiple #ifdef CONFIG_* blocks, the private statistics, the legacy ioctl()
and compat stuff, MTU change, i decided to cut all the unneeded code and make
an easy short driver from that ...

The things i did not really understand i preserved as-is 8-)
Therefore the code looks that similar in some cases.

I wonder whether the code in

- sl_open()
- sl_close()
- slip_write_wakeup()
- sl_xmit()
- sl_free_netdev()
- sl_sync()
- sl_alloc()
- slip_hangup()
- slip_exit()

could be shared e.g. in some separate module where also
drivers/net/hamradio/mkiss.c could participate?!?

This would need to unify the slip/slcan/mkiss structs.

Additionally mkiss.c does not have something like

    static struct net_device **slip_devs;

and creates the netdevices without parsing a fixed number of devices in
mkiss_open(). But as i'm not a tty specialist i better kept my hands off these
internals ...

Regards,
Oliver
--
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