From: Kevin Curtis <kevin.curtis@farsite.co.uk>
To: "'Francois Romieu'" <romieu@cogenit.fr>, linux-kernel@vger.kernel.org
Subject: RE: Generic HDLC interface continued
Date: Wed, 2 Oct 2002 17:30:03 +0100 [thread overview]
Message-ID: <7C078C66B7752B438B88E11E5E20E72E0EF567@GENERAL.farsite.co.uk> (raw)
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:romieu@cogenit.fr]
Sent: 30 September 2002 21:55
To: linux-kernel@vger.kernel.org
Subject: Re: Generic HDLC interface continued
Krzysztof Halasa <khc@pm.waw.pl> :
[...]
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2002-10-02 16:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-02 16:30 Kevin Curtis [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-10-10 16:27 Generic HDLC interface continued Pavel Selivanov
2002-10-10 19:08 ` Francois Romieu
2002-10-15 20:20 ` Krzysztof Halasa
2002-09-27 21:45 Krzysztof Halasa
2002-09-28 18:21 ` Francois Romieu
2002-09-29 13:49 ` Krzysztof Halasa
2002-09-30 20:54 ` Francois Romieu
2002-09-30 23:48 ` Krzysztof Halasa
2002-10-01 18:01 ` Francois Romieu
2002-10-01 22:09 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7C078C66B7752B438B88E11E5E20E72E0EF567@GENERAL.farsite.co.uk \
--to=kevin.curtis@farsite.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=romieu@cogenit.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).