[lkml]   [2001]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.0 + iproute2
> Igmar Palsenberg writes:
> > we might want to consider changing the error the call gives in case
> > MULTIPLE_TABLES isn't set. -EINVAL is ugly, -ENOSYS should make the error
> > more clear..
> How do I tell the difference between using the wrong system call
> number to invoke an ioctl or socket option change, and making a
> call for a feature I haven't configured into my kernel?

The large tables option is rather strange : Looking at the name I start
thinking that the option is actually already there, but this option
enlarges this table.

When the kernel return -EINVAL I start thinking that the call is actually
supported, but the userspace stuff sends garbage. In this case, it sends
valid data, bit the call isn't there.

I haven't had a real good look at the code, but we might change the
behaviour so that the call fails (same case if NETLINK isn't compiled in,
you get an error when creating the socket).

If this isn't possible (if we don't know what userspace wants when
creating the socket, it's a good idea to print an aditional hint saying
'you might want to compile LARGE TABLES option'.

> I think ENOSYS is just a bad a choice.

Maybe time for a ENOTSUPPORTED or so ?

The config option says :

'If you have routing zones that grow to more than about 64 entries, you
may want to say Y here to speed up the routing process'

Which I assume that it just enlarges the table.

-ENOSYS is bad in this case indeed, but -EINVAL is also bad IMHO.



Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

PGP/GPG key :

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.187 / U:1.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site