From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Sebastian Haas <dev@sebastianhaas.info>
Cc: "Marc Kleine-Budde" <mkl@pengutronix.de>,
linux-can@vger.kernel.org,
"Heinz-Jürgen Oertel" <hj.oertel@t-online.de>,
"Wolfgang Grandegger" <wg@grandegger.com>
Subject: Re: adding can4linux to drivers/char
Date: Sun, 22 Sep 2013 13:01:21 +0200 [thread overview]
Message-ID: <523ECE01.40401@hartkopp.net> (raw)
In-Reply-To: <CADGMhsXaJOpbdCgEAoOguZWX2rS_P0a-H5UDZwUWiHD4Nj=upw@mail.gmail.com>
On 22.09.2013 08:39, Sebastian Haas wrote:
> Am 21.09.2013 20:17 schrieb "Oliver Hartkopp" <socketcan@hartkopp.net
> <mailto:socketcan@hartkopp.net>>:
>>
>> On 21.09.2013 19:09, Marc Kleine-Budde wrote:
>> > On 09/21/2013 06:37 PM, Sebastian Haas wrote:
>> >> As Oliver already pointed out there are a bunch of applications outside
>> >> which may require a can4linux-like chardev API.
>> >>
>> >> But I also agree that merging an additional CAN framework makes not
>> >> much sense. I prefer to port can4linux drivers to SocketCAN for not
>> >> yet supported devices. But we may also think about an emulation of
>> >> chardev based APIs like can4linux to support legacy applications.
>> >
>> > The emulation could probably be done in userspace. I'll ask our
>> > userspace graphics guys how they emulate legacy /dev/fbX on top of drm.
>> >
>>
>> Oh yes!
>>
>> If there would be a solution to handle all this within a user-space driver
>> this would be my favorite solution too.
> Just found CUSE made by Tejun. It is in mainline since 2.6.31. I'm going to
> implement a demo for this.
CUSE really looks promising for legacy CAN APIs!
With that idea every vendor(!) can implement an own CUSE driver to support
_their_ costumers to run legacy apps the customers are not able/willing to
port to native SocketCAN. And then vendor becomes the correct contact person
for his own CAN API and his own CUSE adapter too. A good separation!
I agree with Wolfgang that porting applications to Linux-CAN is the strongly
recommended way. Especially because of the simple SocketCAN API this should be
easy to do in the vast majority of cases.
And adding the few missing drivers (like the Xilinx) as a netdevice driver to
drivers/net/can should be no big deal at all. I assume Xilinx would also be
happy to have their hardware supported by the Linux mainline standard.
Best regards,
Oliver
ps. A prominent project which is using the CUSE concept is the 'OSS proxy'
which creates e.g. legacy /dev/dsp devices used by the Open Sound System.
OSS was the former sound system API standard in Linux 2.4.
https://fedoraproject.org/wiki/Features/OSSProxy
http://sourceforge.net/projects/osspd/
next prev parent reply other threads:[~2013-09-22 11:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-20 23:03 adding can4linux to drivers/char Heinz-Jürgen Oertel
2013-09-21 9:17 ` Oliver Hartkopp
2013-09-21 19:57 ` Wolfgang Grandegger
2013-09-21 13:38 ` Marc Kleine-Budde
2013-09-21 16:37 ` Sebastian Haas
2013-09-21 17:09 ` Marc Kleine-Budde
2013-09-21 18:17 ` Oliver Hartkopp
[not found] ` <CADGMhsXaJOpbdCgEAoOguZWX2rS_P0a-H5UDZwUWiHD4Nj=upw@mail.gmail.com>
2013-09-22 10:40 ` Marc Kleine-Budde
2013-09-22 11:01 ` Oliver Hartkopp [this message]
2013-09-23 13:46 ` Marc Kleine-Budde
2013-09-21 19:55 ` Wolfgang Grandegger
2013-09-29 16:28 ` Heinz-Jürgen Oertel
2013-09-29 17:44 ` Marc Kleine-Budde
2013-09-29 17:45 ` Sebastian Haas
2013-09-29 18:44 ` Marc Kleine-Budde
2013-09-29 19:23 ` Max S.
2013-09-29 19:17 ` Heinz-Jürgen Oertel
2013-09-29 19:43 ` autobaud detection (was: Re: adding can4linux to drivers/char) Marc Kleine-Budde
2013-09-30 7:30 ` adding can4linux to drivers/char Sebastian Haas
2013-09-30 10:20 ` Kurt Van Dijck
2013-09-29 19:23 ` Heinz-Jürgen Oertel
2013-09-30 9:35 ` Oliver Hartkopp
2013-10-01 20:20 ` AW: " May, Stefan
2013-10-02 7:49 ` Oliver Hartkopp
2013-10-02 8:43 ` Linux CAN CUSE hacks, SocketCAN and RT Was: " Pavel Pisa
2013-10-02 9:47 ` Wolfgang Grandegger
2013-09-29 19:41 ` Wolfgang Grandegger
2013-09-30 7:40 ` Sebastian Haas
2013-09-30 8:21 ` Wolfgang Grandegger
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=523ECE01.40401@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=dev@sebastianhaas.info \
--cc=hj.oertel@t-online.de \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=wg@grandegger.com \
/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 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).