> -----Original Message----- > From: [email protected] [mailto:socketcan-core- > [email protected]] On Behalf Of Oliver Hartkopp > Sent: Saturday, February 27, 2010 3:38 PM > To: Kurt Van Dijck > Cc: [email protected] > Subject: Re: struct sockaddr_can for j1939 > > Kurt Van Dijck wrote: > > On Fri, Feb 26, 2010 at 12:15:35PM +0100, Kurt Van Dijck wrote: > > > >>> Who want's to use can-raw in J1939 environments then? > > In my perception, J1939 clearly specifies 11bit is allowed on its > bus, > > but not handled by J1939. Although this info is from 8 years back or > so. > > Yes, it is like this. My question should be seen as > > "Who want's to use can-raw in J1939-only environments then?" > > :-) > > >> that's like asking: who want's to use ethernet in IP environments? > >> It's not forbidden. But sticking to j1939 keeps you from mistakes > >> against the j1939 protocol. > > rather innocent phrase, but it makes me think I should go for a > seperate > > address family, just as IP is seperated from ethernet. > > I understand it means some extra work, but looking at af_can.c must > help > > a great deal. > > I consider this a wild idea, but I do not find where it is wrong. > > IMO creating a PF_J1939 goes far beyond the users needs. As you know > usually > J1939 implementations are completely running in userspace ... and > people are > also happy with that. I second that, I know people doing this (J1939 userspace library) and they are using cansocket as low level driver.
> > J1939 is 'just one definition' of what you can do with CAN frames. > Therefore > putting some of it's (timecritical & segmenting) functionalities inside > the > kernel in a new protocol inside PF_CAN is the appropriate way, IMO. IMO, I wouldn't touch the PF_CAN or I would just put inside PF_CAN only what cannot be done in userspace like critical timing. In fact, maybe I would try some Real-Time kernel variant before trying to modify socketcan to solve timing problems (50ms are not hard to meet). Cheers!, Leandro Gentili > Regards, > Oliver > > _______________________________________________ > Socketcan-core mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/socketcan-core _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
