RE: Generic HDLC interface continued

[Kevin Curtis]

Hi,
	sorry that I am miles behind the discussion.  I'll try and keep up
in future.  I think I raised this with Krzysztof on Friday when I noted that
hdlc-2.4.19a.patch seemed to change the configuration interface, and the
utility we use to configure the FarSync card now no longer worked.

	We used the type, data pointer and length in the following way:

If the type indicated that the information was for the card (i.e. not the
driver), then this was passed by a pointer and length to the driver, which
then copied it into shared memory so that the card could then pick it up.
The format of the information was between the utility and the card itself.

Now, when I looked at mapping this into the new structure I had a bit of
difficulty.  I asked if the mechanism could be re-instated.

Surely we could find room for these three items somewhere in the new
structure???

struct if_settings
{
	unsigned int type;	/* Type of physical device or protocol */
	unsigned int data_length; /* device/protocol data length */
	void * data;		/* pointer to data, ignored if length = 0 */
};

Kevin

-----Original Message-----
From: Francois Romieu [mailto:[e-mail]]
Sent: 30 September 2002 21:55
To: [e-mail]
Subject: Re: Generic HDLC interface continued

Krzysztof Halasa <[e-mail]> :
[...]
> Not exactly. The caller always knows meaning of the returned value
> (or it reports error etc). The caller doesn't just know size of the value
> _in_advance_, as it isn't constant. Still, meaning of the variable portion
> of the data is defined by the constant part.

The caller doesn't know size in advance but he gets 'type' and 'size' at
the same time. Why shouldn't 'size' be deduced from 'type' ?

-- 
Ueimor