On Tue, Feb 09, 2010 at 10:33:05AM +0100, Wolfgang Grandegger wrote:
> Hi Kurt,
>
> Kurt Van Dijck wrote:
> > Hi,
> >
> > I'm working on a j1939 socket type (not sure our managament will allow
> > us to open source it, we're working on that too).
> > During that development, we added an extra entry in
> > struct sockaddr_can.can_addr.
> > ----
> >
> > Our extension does increase the size of struct sockaddr_can
> > This patch solves a problem that 'regular' socket types
> > do require the full struct sockaddr_can be present, while using only the
> > first few fields.
> >
> > It does so by not testing on sizeof() but using a newly introduced macro
> > 'partial_struct_size', which returns the size of the struct up to the
> > requested struct member.
> > When socketcan is compiled with bigger struct sockaddr_can, It will not
> > pose any problems with userspace binaries that got compiled with older
> > revisions of struct sockaddr_can.
> > Please not that the 'partial_struct_size' macro can only work when the
> > struct in only added to, not modified, which is the case here.
> >
> > Signed-off-by: Kurt Van Dijck <[email protected]>
>
> Looks special.
Thank you :-)
> Is the problem not solve with unions?
The real problem solved is binary compatibility. userspace programs
compiled with regular 'struct sockaddr_can' would not work with kernel
with newer (bigger) 'struct sockaddr_can' for a 'raw' socket, because of
_unused_ struct members.
So, extending a kernel with other protocols requires me to rebuild all
CAN related userspace tools,
including those that don't rely on/interfere with the newer protocol.
> Anyhow, there is no
> user of this code. Why should we add it?
1) it does not add real code. The preprocessor gets some extra job.
2) The test on sizeof(*addr) tests way too far in memory. If only the
first 'int' is used, why would raw.c require a bunch of memory?
You can look at it as a 'more precise test'?
3) I assume such problem did occur with the introduction of isotp too.
An advantage of socketcan is that protocols can be stacked. The struct
sockaddr_can is the only thing blocking development of other protocols.
4) Making the size of struct sockaddr_can variable is not so strange as
it seems.
* All API calls assume it variable since the API calls deal with
sockets in general.
* the struct sockaddr_un (unix sockets) deal with variable sized
structs in my experience.
The newly introduce 'code' does not add features, nor does it add
'functions', but it add 'flexibility'.
Since CAN is a rather raw protocol, a lot of field busses build upon it.
J1939 is just one of them. Most of them provide _some_ addressing
scheme. I'd dislike telling this would not be possible to integrate in
socketCAN kernel.
Yes, I defend that putting all stuff in open source directly is a good
point, but it would still require me to rebuild all userspace code and
not solve my problem.
Therefore, wether or not a protocol is public available is an issue IMO.
And as such, I cannot tell from here if there are users.
I bet some users have extended sockaddr_can, and I would look at them as
'users' of this code.
>
> Wolfgang.
Kurt
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
