From: Francois Romieu <romieu@cogenit.fr>
To: Pavel Selivanov <pavel-linux-kernel@parabel.inc.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Generic HDLC interface continued
Date: Thu, 10 Oct 2002 21:08:26 +0200 [thread overview]
Message-ID: <20021010210826.A17200@fafner.intra.cogenit.fr> (raw)
In-Reply-To: <35278845015.20021010232749@parabel.inc.ru>; from pavel-linux-kernel@parabel.inc.ru on Thu, Oct 10, 2002 at 11:27:49PM +0700
Greetings,
Pavel Selivanov <pavel-linux-kernel@parabel.inc.ru> :
[...]
> 1) I think that hdlc stack should know nothing about my interface type
> (whether it's V.35, DSL, E1/T1, HPPI, ...).
> I'm sure that hdlc stack must provide only protocols support (and a
> configuration utility to configure protocol's parameters only).
> All other job is developer's problem (even crc type).
Then every driver must implement it's own ioctl() and utility.
Ahum...
[...]
> Possible it's reasonable to make another utility like ethertool (called, for
> example, e1tool, mdsltool,...) and complementary header (ioctls, structs,...)
> for configuring interface(for E1: crc4, timeslots,
> ...), and getting stats.
mv sethdlc.c hdlctool.c ?
> 2) If I've understand author's ideology, he is going to implement
> hdlc stack "near" current network stack.
> I mean hdlc_device appends new fields to net_device, so hdlc device
> is still the same device as ethernet, and that's fine.
I'd rather have hdlc_device pointing to it's own net_device instead of
embedding it directly but I won't fight too much about this (so far :o) ).
[struct if_settings and friends]
> Is it really necessary ?
Yes, it's used. It may/will be done slightly differently.
> At my opinion it would be better to use char *,
It provides less type-checking at compile time.
> and to define it in hdlc.h, hdlc/ioctl.h
{hdlc/line}_settings are defined in hdlc/ioctl.h
Others layer 2 protocols may use if_settings (they don't seem to be in a
hurry though :o) ).
[include/linux/if.h - IF_IFACE_XYZ/IF_PROTO_ABC]
> As I understand, it will be never able to make something like
> ppp-over-framerelay...
> But it is widely used, and (for example) negraph in xBSD provide's
> such functionality...
Imho hacking drivers/net/wan/hdlc_fr.c::fr_rx() and hdlc/ioctl.h isn't
the hardest part of ppp-over-fr for those who really need it.
[struct hdlc_device]
> If someone will have to support one more protocol, he have to modify
> hdlc.h (to add new struct in the union)...
Do you have a specific protocol in mind ?
> Why don't we do like this:
[snip, snip]
Admitting there is a heap of ppp-over-fr code waiting to be included and
even if someone is ready to code this all, I'm for a lazyer solution. :o)
--
Ueimor
next prev parent reply other threads:[~2002-10-10 19:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-10 16:27 Generic HDLC interface continued Pavel Selivanov
2002-10-10 19:08 ` Francois Romieu [this message]
2002-10-15 20:20 ` Krzysztof Halasa
-- strict thread matches above, loose matches on Subject: below --
2002-10-02 16:30 Kevin Curtis
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=20021010210826.A17200@fafner.intra.cogenit.fr \
--to=romieu@cogenit.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel-linux-kernel@parabel.inc.ru \
/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).