This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ethernet driver for linux synthetic target available


Martin Buck wrote:
> 
> "Nikolay V. Pyatkov" wrote:
> > > Or even better the generic TUN/TAP driver which obsoletes ethertap.

Sorry I've always been late with the names. And TUN/TAP exist also on 2.0 !

> 
> 100% ACK. Yet another kernel module for functionality that already
> exists is a bad idea. Especially because it'll probably stop compiling
> in a few weeks when the Linux kernel hackers change one of their
> internal kernel APIs again... :-(
> 
> > > I thought of converting that to ecos/synthetic but got confused by what
> > > can or cannot be safely called from it (execve,blocking read,etc)
> >
> > Yes, that was one of the reasons I did not use TUN.
> 
> The blocking problem might be tricky (well, you could always use
> O_NONBLOCK but then you'd have to poll). How do you solve it with your
> driver?
> 
> Another possibility would be aysnchronous IO and mapping the SIGIO from
> Linux to an eCos interrupt. Interestingly, synth_intr.c already seems to
> provide some kind of support for that, but it doesn't look like it's
> fully implemented (it talks about an IO auxiliary that doesn't seem to
> be implemented anywhere). Can anybody comment on that?
> 

SIGIO seems the good way, and I think that UserModeLinux Virtual Networking
does use it too. Note also that under Linux, fcntl+F_SETSIG allow you to remap
the signal to whatever you want, but this is very Linux-specific.

For the "IO auxiliary", I've understood it as a thread or process collaboring
with the synthetic thread. A kind of simu IO manager/framework that has been
left unimplemented ??

> > Also it requires the
> > character device to control its network interface. But the main reason is I
> > need several ecos targets running simultaneously and talking to each other
> > and the host.
> 
> So use one TUN/TAP per eCos target and enable IP forwarding on your
> Linux box or attach the interfaces to the Linux bridge. No need to
> reinvent the wheel. ;-)
> 

I agree... Or one TUN/TAP for one eCos target configured for routing and all
targets talking to each others via other IPC... IMHO, Linux is nowadays so
flexible that it is very doubtable that we ever need some Modules/Patches to
do whatever synthetic.

-- 
Eric DONNAT

Silicomp Research Institute
2 avenue de Vignate, 38610 Gieres, France.
Phone +33 476 63 48 85   Fax +33 476 51 05 32
http://www.ri.silicomp.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]