On 09/27/2011 07:00 PM, Richard Cochran wrote: > On Tue, Sep 27, 2011 at 06:26:44PM +0200, Jan Kiszka wrote: >> On 2011-09-27 18:05, Richard Cochran wrote: >> >> That's a common misunderstanding: RTnet is a networking stack with many >> _optional_ components (like RTmac, RTcfg etc.). I would bet that it's >> more frequently used today in minimal setups, i.e. just the core, some >> driver, and either PF_PACKET or UDP/IP. > > I understood about the modular design, but I really want to know if > rtnet will help me if I want to use of the industrial Ethernet > protocols. AFAICT, rtnet really doesn't offer these. > > So I'll ask the direct question once again. Does rtnet help me with > industrial Ethernet (apart from the rtnet protocols), or not? > >>> Unless rtnet implements (or helps to implement) these, it is kind of >>> silly to say, "your way won't work, you should use rtnet instead." >>> >>> I don't know PowerLink or Profinet, but I do know EtherCAT and IEC >>> 61850, and those two can surely be implemented on the interface that I >>> am talking about. >> >> It works, but it won't give you a deterministic control loop as you >> still have Linux in the game. > > It really depends on how the driver is written. While my gianfar > example does make use of normal Linux driver interrupts, it would not > necessarily have to do so. > >> I was simply hoping to collect some new ideas how to address the driver >> maintenance issue in a better way but without dropping key features >> needed for RT networking. Something like "let's add generic RT channels >> to Linux upstream drivers and then only patch them fit RTDM". Not sure >> if that works, but it would come with a vision how to keep things more >> maintainable. > > Well, can you turn the issue around and convince me that writing a > rtnet driver is the best way to acheive raw Ethernet packet access?
>From the point of view of someone a bit external to the rtnet project, rtnet is a TCP/IP stack, which contains the stack, useless for your purposes, but defines an interface between drivers and the stack. By following this interface to write a driver on one-side, and support for raw packets on the other side you get: - raw packets support for all drivers in rtnet repository - TCP/IP support for the NIC you wrote a driver for. As for the in-kernel driver patch versus out-of-tree driver, in-kernel driver will have to be adapted for each release of the linux kernel, when porting the I-pipe patch, and that is quickly going to become a nightmare. > You talk about the rtnet driver model, but is it described anywhere? > > (BTW rtnet/Documentation/README.drvporting is horrible. It is just a > random list of 40+ odd points without any sense. That document gave me > the impression that developing an rtnet driver is a kind of extended > "hack until it starts working.") README.drvporting is frightening at first, but in fact, the job to port a network driver to rtnet is not so hard. > > Thanks, > Richard > > _______________________________________________ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core > -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
