Hello,
Thanks to all of you who responded to my first RFC on this subject. The
discussion ended up going in the Ethernet direction, and I frankly don't
know whether that applies to this case, or even if it _should_ apply or
they should really be separate config. subsystems. This is another thing
that you may wanna throw your opinions on.
Anyhow, the parameters we currently need to configure on our board (the
PC300) are as follows:
- Media: V.35, RS-232, X.21, T1, E1
- Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
already supported by the 'hw' option)
- Clock: 'ext' (or 0, which implies external clock) or some numeric value
> 0 (which implies internal clock); setting it to 'int' would set
it to some fixed numeric value > 0 (useful for T1/E1 links, just
to indicate master clock as opposed to slave or 'ext' clock)
- Frame Relay only:
- End type: DCE or DTE (maybe this applies to other interface
types as well)
- DLCI: DLC number for the interface
- T1/E1 only:
- Line code:
- Frame mode:
- LBO (T1 only): line-build-out
- Rx Sensitivity: short-haul or long-haul
- Active channels: mask that represents the possible 24/32
channels (timeslots) on a T1/E1 line
I'm sure that _all_ the other sync cards need to configure the _same_
parameters (or a subset of them), and there may be cards that need even
more parameters (but we have to start somewhere ... ;). So having a
unified interface and making the drivers compliant to it is not that hard
and surely would help users to dump the currently ridiculous set of
individual config. tools for these cards (yes, we currently have our own
pc300cfg, along with the -- not absolute -- "standard" sethdlc utility).
I'm willing to go for this implementation, but I wanted to know first:
- whether ifconfig is the right place to do it;
- where I should create the new ioctl's to handle these new parameters.
Suggestions / comments are more than welcome.
Later,
Ivan
Ivan Passos <[email protected]> ?crit :
[...]
> Anyhow, the parameters we currently need to configure on our board (the
> PC300) are as follows:
>
> - Media: V.35, RS-232, X.21, T1, E1
drivers/net/wan/lmc/lmc_media.c:65
char *lmc_t1_cables[] = {
"V.10/RS423", "EIA530A", "reserved", "X.21", "V.35",
"EIA449/EIA530/V.36", "V.28/EIA232", "none", NULL
};
(Where it's used btw).
I don't exactly see the point here: do some of your cards supports these
media at the same time ? I would have believed it to be set in stone.
> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> already supported by the 'hw' option)
+ Transparent HDLC ?
> - Clock: 'ext' (or 0, which implies external clock) or some numeric value
> > 0 (which implies internal clock); setting it to 'int' would set
> it to some fixed numeric value > 0 (useful for T1/E1 links, just
> to indicate master clock as opposed to slave or 'ext' clock)
Ok.
[...]
> - T1/E1 only:
> - Line code:
> - Frame mode:
> - LBO (T1 only): line-build-out
> - Rx Sensitivity: short-haul or long-haul
> - Active channels: mask that represents the possible 24/32
> channels (timeslots) on a T1/E1 line
May I ask what kind of protocol support you have in mind here ?
> I'm sure that _all_ the other sync cards need to configure the _same_
> parameters (or a subset of them), and there may be cards that need even
> more parameters (but we have to start somewhere ... ;). So having a
> unified interface and making the drivers compliant to it is not that hard
> and surely would help users to dump the currently ridiculous set of
> individual config. tools for these cards (yes, we currently have our own
> pc300cfg, along with the -- not absolute -- "standard" sethdlc utility).
>
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;
We can pass (media/clock) through his "media" parameter but I won't claim it
to be sexy. So far, I don't see how we may avoid some tool to do all the
required ioctl.
> - where I should create the new ioctl's to handle these new parameters.
drivers/net/wan/sbni.[ch] uses the SIOCDEVPRIVATE range for different things.
The x25 protocol uses the SIOCPROTOPRIVATE. I'd rather avoid both.
> Suggestions / comments are more than welcome.
--
Ueimor
> - Media: V.35, RS-232, X.21, T1, E1
DS1, DS3, ...
> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> already supported by the 'hw' option)
Not nicely.
> - Clock: 'ext' (or 0, which implies external clock) or some numeric value
> > 0 (which implies internal clock); setting it to 'int' would set
> it to some fixed numeric value > 0 (useful for T1/E1 links, just
> to indicate master clock as opposed to slave or 'ext' clock)
Yep
> I'm sure that _all_ the other sync cards need to configure the _same_
> parameters (or a subset of them), and there may be cards that need even
And more
Generic Z85x30 drivers can run with multiple framing CRC versions (all the
chip can do in theory). So I think you need
bitcoding [NRZ, NRZI]
crctype CRC16, ...
hunt
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;
> - where I should create the new ioctl's to handle these new parameters.
I think a new ioctl would be sensible. There is a lot to go in it.
On Mon, 4 Dec 2000, Ivan Passos wrote:
> Hello,
[snip details...]
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;
I would like to note an objection to using ifconfig to carry all of this.
For example I do not use or even have ifconfig on any of my systems as I
only use/need/want Alexey's ip utility to perform all of those tasks.
I would rather have an independant utility that could set and check the
settings of all of these variables for whatever classes of networking
connections existed. This would provide a cleaner split between the
protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##,
10/100, 4/16/100, etc) parameters.
Such a split should make for a cleaner configuration structure WRT virtual
devices as well which for the most part deal with the protocol config and
do not need much device config.
FWIW: Alexey's ip has replaced both ifconfig and route on my systems.
Something that could now replace having several different card config
utils around with one binary would be fantastic.
> - where I should create the new ioctl's to handle these new parameters.
>
> Suggestions / comments are more than welcome.
>
> Later,
> Ivan
Thanks! I will volunteer to test/break/etc as my coding skills verge
beyond ludicrous.
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250
Email: [email protected]
WWW: http://www.paktronix.com
--------------------------------------------------
I have a vested interest in how this all turns out. I own a Packet Over SONET
device driver for our OC-12 and OC-48 NICs that I currently pass all parameters
to the driver via arguments on the insmod. To avoid lengthy commands, we
provide the common defaults. We accept some basic ifconfig input, but with
SONET/SDH and chip specific items that needed to be controlled, ifconfig did not
seem the way to go.
Thanks!
Greg
--
Greg Parrott
Lucent Technologies, Inc.
Optical Area Networking
(919) 838-6095
http://www.lucent-optical.com/oan
Alan Cox wrote:
> > - Media: V.35, RS-232, X.21, T1, E1
> DS1, DS3, ...
>
> > - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> > already supported by the 'hw' option)
>
> Not nicely.
>
> > - Clock: 'ext' (or 0, which implies external clock) or some numeric value
> > > 0 (which implies internal clock); setting it to 'int' would set
> > it to some fixed numeric value > 0 (useful for T1/E1 links, just
> > to indicate master clock as opposed to slave or 'ext' clock)
>
> Yep
>
> > I'm sure that _all_ the other sync cards need to configure the _same_
> > parameters (or a subset of them), and there may be cards that need even
>
> And more
>
> Generic Z85x30 drivers can run with multiple framing CRC versions (all the
> chip can do in theory). So I think you need
>
> bitcoding [NRZ, NRZI]
> crctype CRC16, ...
> hunt
>
> > I'm willing to go for this implementation, but I wanted to know first:
> > - whether ifconfig is the right place to do it;
> > - where I should create the new ioctl's to handle these new parameters.
>
> I think a new ioctl would be sensible. There is a lot to go in it.
From: "Ivan Passos" <[email protected]>
> the parameters we currently need to configure on our board (the
> PC300) are as follows:
>
> - Media: V.35, RS-232, X.21, T1, E1
> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> already supported by the 'hw' option)
> - Clock: 'ext' (or 0, which implies external clock) or some numeric value
> > 0 (which implies internal clock); setting it to 'int' would set
> it to some fixed numeric value > 0 (useful for T1/E1 links, just
> to indicate master clock as opposed to slave or 'ext' clock)
> - Frame Relay only:
> - End type: DCE or DTE (maybe this applies to other interface
> types as well)
> - DLCI: DLC number for the interface
> - T1/E1 only:
> - Line code:
> - Frame mode:
> - LBO (T1 only): line-build-out
> - Rx Sensitivity: short-haul or long-haul
> - Active channels: mask that represents the possible 24/32
> channels (timeslots) on a T1/E1 line
Some others (less common):
- Serial Encoding (NRZ/NRZI)
- Transmit Idle Mode (Flags/Marks)
- Transmit Preamble
> having a unified interface and making the drivers compliant to it is not
that hard
> and surely would help users to dump the currently ridiculous set of
> individual config. tools for these cards (yes, we currently have our own
> pc300cfg, along with the -- not absolute -- "standard" sethdlc utility).
>
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;
> - where I should create the new ioctl's to handle these new parameters.
The ioctl interface is more universally applicable for my driver
(synclink.c) which offers both the network oriented sync interface
*and* a tty oriented sync interface.
Paul Fulghum [email protected]
Microgate Corporation http://www.microgate.com
On Tue, 5 Dec 2000, Francois Romieu wrote:
> Ivan Passos <[email protected]> ?crit :
> >
> > - Media: V.35, RS-232, X.21, T1, E1
>
> I don't exactly see the point here: do some of your cards supports these
> media at the same time ? I would have believed it to be set in stone.
Yes. The PC300/RSV supports RS-232 and V.35, software selectable. The
PC300/TE supports T1 and E1, also software selectable.
> > - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> > already supported by the 'hw' option)
>
> + Transparent HDLC ?
As I said, for sure there will be parameters left out, but this would be
my _initial_ set of parameters. Subsequent patches would add more and more
parameters.
> > - T1/E1 only:
> > - Line code:
> > - Frame mode:
> > - LBO (T1 only): line-build-out
> > - Rx Sensitivity: short-haul or long-haul
> > - Active channels: mask that represents the possible 24/32
> > channels (timeslots) on a T1/E1 line
>
> May I ask what kind of protocol support you have in mind here ?
Same protocols as before: Frame Relay, X.25, PPP, HDLC ... Did I
misunderstood your question??
> We can pass (media/clock) through his "media" parameter but I won't claim it
> to be sexy. So far, I don't see how we may avoid some tool to do all the
> required ioctl.
The point is not to prevent the tool from doing ioctl's, is having _one
single_ tool that generates _the same_ ioctl to all sync drivers. That
would mean that a user wouldn't care if his sync card is from X, Y or Z
manufacturer, the command syntax to set a specific link configuration
would be the same for all of them. How to translate this standard command
to the hardware, that's a device driver problem (no news here).
> > - where I should create the new ioctl's to handle these new parameters.
>
> drivers/net/wan/sbni.[ch] uses the SIOCDEVPRIVATE range for different things.
> The x25 protocol uses the SIOCPROTOPRIVATE. I'd rather avoid both.
That's what everybody does currently, but each driver uses their _own_ set
of ioctl's. Having one unified set of ioctl's for all drivers would ease
the user's life a lot.
Later,
Ivan
On Tue, 5 Dec 2000, Alan Cox wrote:
>
> I think a new ioctl would be sensible. There is a lot to go in it.
Alan, what's the approach you'd feel more comfortable with:
- One ioctl that passes a pointer to a known structure in ifr.ifr_data as
its argument.
- Several ioctl's, one for each parameter, that pass only the specific
parameter new value as the argument.
The former is good because it relies on a _single_ ioctl. However, every
time you change the ioctl structure you may lose backward compatibility.
The latter is good because new implementations / features won't affect
previous working features. However, it'd create a huge list of ioctl's.
Please let me know whatcha think.
Later,
Ivan
On Tue, 5 Dec 2000, Matthew G. Marsh wrote:
>
> I would like to note an objection to using ifconfig to carry all of this.
> For example I do not use or even have ifconfig on any of my systems as I
> only use/need/want Alexey's ip utility to perform all of those tasks.
>
> I would rather have an independant utility that could set and check the
> settings of all of these variables for whatever classes of networking
> connections existed. This would provide a cleaner split between the
> protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##,
> 10/100, 4/16/100, etc) parameters.
>
> Such a split should make for a cleaner configuration structure WRT virtual
> devices as well which for the most part deal with the protocol config and
> do not need much device config.
>
> FWIW: Alexey's ip has replaced both ifconfig and route on my systems.
> Something that could now replace having several different card config
> utils around with one binary would be fantastic.
Very good point IMHO. I'll have a look at ip to see if I can get ideas
from it. Thanks for the info!!
Later,
Ivan
On Tue, 5 Dec 2000, Mark Cooke wrote:
>
> struct foo {
> unsigned int crufty_compatability_number;
> .
> .
> .
> };
>
> ?
The problem is not this, but structure alignment and copy_[to|from]_user
operations. This approach, although it's my preferred one (due to being
self-contained), requires synchronization between kernel and utility, and
this sometimes is not always true.
Anyhow, I still prefer this approach over the "tons of different ioctl's"
one. I'd like to get the opinion of the community though (especially
Alan).
Later,
Ivan
[Ivan Passos]
> - One ioctl that passes a pointer to a known structure in
> ifr.ifr_data as its argument.
struct sync_params_ioctl_data {
int opcode;
union {......
Seems straightforward to me. Basically just ioctl numbers within ioctl
numbers.
Peter
> Alan, what's the approach you'd feel more comfortable with:
> - One ioctl that passes a pointer to a known structure in ifr.ifr_data as
> its argument.
> - Several ioctl's, one for each parameter, that pass only the specific
> parameter new value as the argument.
>
> The former is good because it relies on a _single_ ioctl. However, every
> time you change the ioctl structure you may lose backward compatibility.
One ioctl with a set of subcommands seems to be quite common
>
> I have a vested interest in how this all turns out. I own a Packet Over SONET
> device driver for our OC-12 and OC-48 NICs that I currently pass all parameters
> to the driver via arguments on the insmod. To avoid lengthy commands, we
> provide the common defaults. We accept some basic ifconfig input, but with
> SONET/SDH and chip specific items that needed to be controlled, ifconfig did not
> seem the way to go.
Ditto, we have an adsl driver that we setup by overloading various otherwise
unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
faster than writing yet another ioctl using device configuration agent, but
distasteful non the less.
Some generic way to pass configuration data using a generic configuration
agent to network (and other) drivers would be interesting.
> > > I'm willing to go for this implementation, but I wanted to know first:
> > > - whether ifconfig is the right place to do it;
> > > - where I should create the new ioctl's to handle these new parameters.
> >
> > I think a new ioctl would be sensible. There is a lot to go in it.
--
__O
Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[email protected]> http://www.lineo.com 604-461-7532
> Ditto, we have an adsl driver that we setup by overloading various otherwise
> unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
> faster than writing yet another ioctl using device configuration agent, but
> distasteful non the less.
Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
pondering is if we should make the hardware config ioctl take a hardware type
ident with each struct. That would help make all the ethernet agree, all the
wan agree, all the ADSL agree without making a nasty mess.
>
On Wed, 6 Dec 2000, Alan Cox wrote:
> > Ditto, we have an adsl driver that we setup by overloading various otherwise
> > unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
> > faster than writing yet another ioctl using device configuration agent, but
> > distasteful non the less.
> Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
> pondering is if we should make the hardware config ioctl take a hardware type
> ident with each struct. That would help make all the ethernet agree, all the
> wan agree, all the ADSL agree without making a nasty mess.
Id be up for that, but its hard to standardize on IOCTLs without people
publishing their drivers, as long as people hide their code we dont know
what everyone else is doing config interface wise...
Lets see the code, people...
-Dan
On Tue, Dec 05, 2000 at 05:34:50PM -0800, Dan Hollis wrote:
> On Wed, 6 Dec 2000, Alan Cox wrote:
> > > Ditto, we have an adsl driver that we setup by overloading various otherwise
> > > unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
> > > faster than writing yet another ioctl using device configuration agent, but
> > > distasteful non the less.
> > Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
> > pondering is if we should make the hardware config ioctl take a hardware type
> > ident with each struct. That would help make all the ethernet agree, all the
> > wan agree, all the ADSL agree without making a nasty mess.
>
> Id be up for that, but its hard to standardize on IOCTLs without people
> publishing their drivers, as long as people hide their code we dont know
> what everyone else is doing config interface wise...
>
> Lets see the code, people...
We are trying to get permission from the customer to release it.
--
__O
Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[email protected]> http://www.lineo.com 604-461-7532
Alan Cox <[email protected]> writes:
> Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
> pondering is if we should make the hardware config ioctl take a hardware type
> ident with each struct. That would help make all the ethernet agree, all the
> wan agree, all the ADSL agree without making a nasty mess.
What's wrong with returning -Exxx error code when the user requests
unsupported interface or function?
I think we should just #define possible values in standard include file
and make ifconfig/ip use it. We can add additional media types as
required.
2.5 task IMHO.
I think we need few ioctl calls: get + set media (int argument),
get + set speed (probably two - RX and TX), etc.
In my 2.4 HDLC stuff - to be published :-( - there something like that
(in private ioctl range, of course).
--
Krzysztof Halasa
Network Administrator
> I think we need few ioctl calls: get + set media (int argument),
> get + set speed (probably two - RX and TX), etc.
> In my 2.4 HDLC stuff - to be published :-( - there something like that
> (in private ioctl range, of course).
I think we are agreeing
I'm saying use something like
struct
{
u16 media_group;
union
{
struct hdlc_physical ...
struct hdlc_bitstream
struct hdlc_protocol
struct fr_protocol
struct eth_physical
struct atm_physical
struct dsl_physical
struct dsl_bitstream
struct tr_physical
struct wireless_physical
struct wireless_80211
struct wireless_auth
} config;
}
Alan
Alan Cox wrote:
>
> > I think we need few ioctl calls: get + set media (int argument),
> > get + set speed (probably two - RX and TX), etc.
> > In my 2.4 HDLC stuff - to be published :-( - there something like that
> > (in private ioctl range, of course).
>
> I think we are agreeing
>
> I'm saying use something like
>
> struct
> {
> u16 media_group;
> union
> {
> struct hdlc_physical ...
> struct hdlc_bitstream
> struct hdlc_protocol
> struct fr_protocol
> struct eth_physical
Not yet another one for eth... We now have ethtool for this. And a
generic netdevice::set_config wrapper can be created that simply calls
the ethtool ioctl with the proper info and locking.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
> > struct hdlc_protocol
> > struct fr_protocol
> > struct eth_physical
>
> Not yet another one for eth... We now have ethtool for this. And a
> generic netdevice::set_config wrapper can be created that simply calls
> the ethtool ioctl with the proper info and locking.
There I disagree. I would do it the other way up. Post 2.4 you make the
ethtool ioctl simply build an eth_physical and run in that way. Right now
the ethtool stuff is a bit hackish and cannot handle upcoming real world
situations such as setting the cryptokey for onboard crypto on ethernet
cards, or handling devices that present themselves as ethernet but are not
at the physical layer being remotely honest about it.
Alan
I can't print and I found this in the logs:
Dec 9 16:10:49 ozob kernel: parport0: Nibble timeout at event 9 (0 bytes)
Dec 9 16:11:29 ozob last message repeated 4 times
Dec 9 16:12:39 ozob last message repeated 7 times
Dec 9 16:13:40 ozob last message repeated 6 times
If I reboot, then I can print for a while and then this repeats.
Can anyone tell me what this means and what to do about it?
kernel: 2.4.0-test12-pre7 (same problem with pre3)
cpu: intel 686
printer: hp4500
kernel setup:
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y
CONFIG_PRINTER=y
I can supply any information necessary.
Thanks,
::::: Gene Imes http://www.ozob.net :::::
Alan Cox <[email protected]> writes:
> I think we are agreeing
>
>
> I'm saying use something like
>
> struct
> {
> u16 media_group;
> union
> {
> struct hdlc_physical ...
> struct hdlc_bitstream
> struct hdlc_protocol
> struct fr_protocol
> struct eth_physical
> struct atm_physical
> struct dsl_physical
> struct dsl_bitstream
> struct tr_physical
> struct wireless_physical
> struct wireless_80211
> struct wireless_auth
> } config;
> }
I think union like this is fine.
We currently have:
ioctl(sock, COMMAND, ifreq*)
where ifreq is defined in include/linux/if.h and is 16 bytes long:
struct ifreq {
{
char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */
} ifr_ifrn;
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short ifru_flags;
int ifru_ivalue;
int ifru_mtu;
struct ifmap ifru_map;
char ifru_slave[IFNAMSIZ]; /* Just fits the size */
char ifru_newname[IFNAMSIZ];
char * ifru_data;
}
I understand we can put a config structure address in ifru_data - but
do we really need another level?
Wouldn't it be better put config structs there (in the union)?
It would then read:
struct ifreq {
{
char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */
} ifr_ifrn;
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short ifru_flags;
int ifru_ivalue;
int ifru_mtu;
struct ifmap ifru_map;
char ifru_slave[IFNAMSIZ]; /* Just fits the size */
char ifru_newname[IFNAMSIZ];
char * ifru_data;
struct hdlc_physical ...
struct hdlc_bitstream
struct hdlc_protocol
struct fr_protocol
struct eth_physical
struct atm_physical
struct dsl_physical
struct dsl_bitstream
struct tr_physical
struct wireless_physical
struct wireless_80211
struct wireless_auth
}
while I'd put "media_group" in ioctl command code:
#define SIOCSHDLC_PHY ...
#define SIOCGHDLC_PHY ... /* get */
#define SIOCSFR ...
#define SIOCSETH_PHY ...
#define SIOCSATM...
A possible problem is if the struct gets longer - we would have to recompile
all utils using it. Doing that before distributions start using 2.4 as
a kernel for general use would save us (we can use pointers in such cases
as well, as some operations - downloading firmware or crypto keys - may have
very long data areas).
What do you think about it?
--
Krzysztof Halasa
Network Administrator