Re: 2.4.0 + iproute2

2001-01-17 Thread Igmar Palsenberg
> The underlying problem is of course that all those sanity checks should > be done in user space, not in the kernel. > > (See also ftp://icaftp.epfl.ch/pub/people/almesber/slides/tmp-tc.ps.gz > The bitching starts on slide 11, some ideas for fixing the problem on > slide 16, but heed the warnin

Re: 2.4.0 + iproute2

2001-01-17 Thread Andi Kleen
On Wed, Jan 17, 2001 at 06:04:33PM +0100, Werner Almesberger wrote: > (See also ftp://icaftp.epfl.ch/pub/people/almesber/slides/tmp-tc.ps.gz > The bitching starts on slide 11, some ideas for fixing the problem on > slide 16, but heed the warning on slide 15.) Thanks for the pointer. > > Beside

Re: 2.4.0 + iproute2

2001-01-17 Thread Werner Almesberger
Andi Kleen wrote: > Configuring a complex subsystem like CBQ which has dozens of parameters > with only a single ed'esque error message (EINVAL) when something goes > wrong is just bad. The underlying problem is of course that all those sanity checks should be done in user space, not in the kerne

Re: 2.4.0 + iproute2

2001-01-14 Thread Igmar Palsenberg
> > Using textual strings means you can't use standard functions. An option > > would be to extend the call so that if the userspace app wants to know > > what really went wrong he can ask the kernel. > > That will not work. Consider an application that has multiple rtnetlink > sockets open, whi

Re: 2.4.0 + iproute2

2001-01-14 Thread Andi Kleen
On Sun, Jan 14, 2001 at 05:15:53AM -0800, David S. Miller wrote: > > Andi Kleen writes: > > David's /proc/errno_strings > > David put a smiley at the end of that sentence, he was kidding and was > trying to show you how rediculious keeping errno strings in the kernel > is. You think it is less

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
Igmar Palsenberg writes: > > People must be really suffering right now, and we ought to get > > /proc/errno_strings implemented as soon as possible... :-) > First the help describing large tables should be changed. I agree, someone feel free to propose a patch. > String errors don't belong

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
Andi Kleen writes: > David's /proc/errno_strings David put a smiley at the end of that sentence, he was kidding and was trying to show you how rediculious keeping errno strings in the kernel is. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscrib

Re: 2.4.0 + iproute2

2001-01-14 Thread Andi Kleen
On Sun, Jan 14, 2001 at 01:13:16PM +0100, Igmar Palsenberg wrote: > On Sun, 14 Jan 2001, Andi Kleen wrote: > > > On Sun, Jan 14, 2001 at 03:36:55AM -0800, David S. Miller wrote: > > > > > > Andi Kleen writes: > > > > How would you pass the extended errors? As strings or as to be > > > > defined

Re: 2.4.0 + iproute2

2001-01-14 Thread Igmar Palsenberg
> People must be really suffering right now, and we ought to get > /proc/errno_strings implemented as soon as possible... :-) First the help describing large tables should be changed. It's wrong. String errors don't belong in kernel space IMHO. Igmar -- -- Igmar Palsenberg JDI Media

Re: 2.4.0 + iproute2

2001-01-14 Thread Igmar Palsenberg
On Sun, 14 Jan 2001, Andi Kleen wrote: > On Sun, Jan 14, 2001 at 03:36:55AM -0800, David S. Miller wrote: > > > > Andi Kleen writes: > > > How would you pass the extended errors? As strings or as to be > > > defined new numbers? I would prefer strings, because the number > > > namespace could

Re: 2.4.0 + iproute2

2001-01-14 Thread Igmar Palsenberg
> 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

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
Andi Kleen writes: > > Textual error messages for system calls never belong in the kernel. > > Put it in glibc or wherever. > > This just means that a table needs to be kept in sync between glibc and > netlink, and if someone e.g. gets a new CBQ module he would need to update > glibc. It's

Re: 2.4.0 + iproute2

2001-01-14 Thread Andi Kleen
On Sun, Jan 14, 2001 at 03:36:55AM -0800, David S. Miller wrote: > > Andi Kleen writes: > > How would you pass the extended errors? As strings or as to be > > defined new numbers? I would prefer strings, because the number > > namespace could turn out to be as nasty to maintain as the current

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
Andi Kleen writes: > How would you pass the extended errors? As strings or as to be > defined new numbers? I would prefer strings, because the number > namespace could turn out to be as nasty to maintain as the current > sysctl one. Textual error messages for system calls never belong in the

Re: 2.4.0 + iproute2

2001-01-14 Thread Andi Kleen
On Sun, Jan 14, 2001 at 02:55:28AM -0800, David S. Miller wrote: > > Andi Kleen writes: > > In my opinion (rt)netlink would benefit a lot from introducing 5-10 > > new errnos and possibly a new socket option to get a string/number > > with the exact error. > > Introducing 5-10 new errnos just

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
Andi Kleen writes: > In my opinion (rt)netlink would benefit a lot from introducing 5-10 > new errnos and possibly a new socket option to get a string/number > with the exact error. Introducing 5-10 new errnos just for rtnetlink is a big waste when we already have socket extended errors which

Re: 2.4.0 + iproute2

2001-01-14 Thread Andi Kleen
On Sun, Jan 14, 2001 at 01:17:54AM -0800, David S. Miller wrote: > > 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 differe

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
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 optio

Re: 2.4.0 + iproute2

2001-01-14 Thread Igmar Palsenberg
> > > You forgot to set CONFIG_IP_ADVANCED_ROUTER > > > > Nope. Still the same error after that one is set : > > > > CONFIG_IP_ADVANCED_ROUTER=y > > Try CONFIG_IP_MULTIPLE_TABLES. Yep, that was the one.. we might want to consider changing the error the call gives in case MULTIPLE_TABLES is

Re: 2.4.0 + iproute2

2001-01-14 Thread David S. Miller
Igmar Palsenberg writes: > > > ./ip rule list > > > RTNETLINK answers: Invalid argument > > > Dump terminated > > > > You forgot to set CONFIG_IP_ADVANCED_ROUTER > > Nope. Still the same error after that one is set : > > CONFIG_IP_ADVANCED_ROUTER=y Try CONFIG_IP_MULTIPLE_TABLES. Late

Re: 2.4.0 + iproute2

2001-01-14 Thread Igmar Palsenberg
> On Sat, Jan 13, 2001 at 05:37:01PM +0100, Igmar Palsenberg wrote: > > Hi, > > > > kernel : 2.4.0 vanilla > > iproute2 version : ss001007 > > > > After building I've got a few problems : > > > > ./ip rule list > > RTNETLINK answers: Invalid argument > > Dump terminated > > You forgot to set CONFI

Re: 2.4.0 + iproute2

2001-01-14 Thread Harald Welte
On Sat, Jan 13, 2001 at 05:37:01PM +0100, Igmar Palsenberg wrote: > Hi, > > kernel : 2.4.0 vanilla > iproute2 version : ss001007 > > After building I've got a few problems : > > ./ip rule list > RTNETLINK answers: Invalid argument > Dump terminated You forgot to set CONFIG_IP_ADVANCED_ROUTER