From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
To: Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Cc: SocketCAN Core Mailing List
<socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>,
Linux Netdev List
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH net-next-2.6] can: add slcan driver for serial/USB-serial CAN adapters
Date: Tue, 30 Nov 2010 17:40:49 +0100 [thread overview]
Message-ID: <4CF52911.6030900@hartkopp.net> (raw)
In-Reply-To: <20101129233718.45dee61d-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On 30.11.2010 00:37, Alan Cox wrote:
> On Mon, 29 Nov 2010 21:30:45 +0100
> Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> 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
next prev parent reply other threads:[~2010-11-30 16:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 20:30 [PATCH net-next-2.6] can: add slcan driver for serial/USB-serial CAN adapters Oliver Hartkopp
2010-11-29 23:37 ` Alan Cox
[not found] ` <20101129233718.45dee61d-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2010-11-30 16:40 ` Oliver Hartkopp [this message]
[not found] ` <4CF52911.6030900-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
2010-12-02 20:57 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CF52911.6030900@hartkopp.net \
--to=socketcan-fj+pqtutwrtk1umjsbkqmq@public.gmane.org \
--cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.