2.4.0 + iproute2

2.4.0 + iproute2

[Igmar Palsenberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 451 bytes --]

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

Version should be OK according to the Changes file.

config is attached


        Regards,


		Igmar

-- 

--
Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar

[-- Attachment #2: Type: TEXT/PLAIN, Size: 3048 bytes --]

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y

#
# Processor type and features
#
CONFIG_M586TSC=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_NOHIGHMEM=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETFILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_LOG=y

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDE_MODES=y

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y

#
# Ethernet (1000 Mbit)
#
CONFIG_PPP=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_DEFLATE=y

#
# ISDN subsystem
#
CONFIG_ISDN=y

#
# Passive ISDN cards
#
CONFIG_ISDN_DRV_HISAX=y
CONFIG_HISAX_EURO=y
CONFIG_HISAX_16_3=y

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# Mice
#
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y

#
# File systems
#
CONFIG_QUOTA=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y

#
# Partition Types
#
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_1=y

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y

Re: 2.4.0 + iproute2

[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

> Version should be OK according to the Changes file.
> 
> config is attached
> 
> 
>         Regards,
> 		Igmar
-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 CONFIG_IP_ADVANCED_ROUTER

Nope. Still the same error after that one is set :

CONFIG_IP_ADVANCED_ROUTER=y

[root@base root]# ip rule list
RTNETLINK answers: Invalid argument
Dump terminated

According to net/ipv4/Config.in :

if [ "$CONFIG_IP_ADVANCED_ROUTER" = "y" ]; then
   define_bool CONFIG_RTNETLINK y
   define_bool CONFIG_NETLINK y

CONFIG_IP_ADVANCED_ROUTER just sets those two values, and adapts the
questions. To make sure I just recompiled with Advanced Router turned on,
and still the same error.

I tested the other command of the ip command, and this one is the only one
that gives problems, the others are fine.




	Regards,


		Igmar



-- 

--
Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 isn't set. -EINVAL is ugly, -ENOSYS should make the error
more clear..

> Later,
> David S. Miller
> davem@redhat.com


Thanx,

		Igmar


-- 

--
Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 option change, and making a
call for a feature I haven't configured into my kernel?

I think ENOSYS is just a bad a choice.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 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?
> 
> I think ENOSYS is just a bad a choice.

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.
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.


-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 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 warning on slide 15.)

Besides that, I agree that we have far too many EINVALs in the kernel.
Maybe we should just record file name and line number of the EINVAL
in *current and add an eh?(2) system call ;-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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. 

> 
> Besides that, I agree that we have far too many EINVALs in the kernel.
> Maybe we should just record file name and line number of the EINVAL
> in *current and add an eh?(2) system call ;-)

In the end you come to text strings, if you like it or not ;) 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 warning on slide 15.)
> 
> Besides that, I agree that we have far too many EINVALs in the kernel.
> Maybe we should just record file name and line number of the EINVAL
> in *current and add an eh?(2) system call ;-)

I don't care about an error, but EINVAL is giving very confusing
errors.. Like finding your glasses when you're already have them on.

I like the h_errno solution, but that's another glibc change.

> - Werner


	Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 are perfect for this
purpose.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 for rtnetlink is a big waste when we
> already have socket extended errors which are perfect for this
> purpose.

Just makes the interface rather complicated for the user, but ok. 

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. 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 kernel.
Put it in glibc or wherever.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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
>  > sysctl one.
> 
> 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 also bad for maintainers, because patches for tables of number 
tend to always reject ;) 

Textual error messages are e.g. used by plan9 and would be somewhat similar
to /proc. It would probably waste a few bytes in the kernel, but that's not
too bad, given the work it saves. e.g. rusty's code usually has a debug option 
that you can set and where each EINVAL outputs a error message; i always found 
that very useful and sometimes hacked that into other subsystems in my 
private tree.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 turn out to be as nasty to maintain as the current
> >  > sysctl one.
> >
> > 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 also bad for maintainers, because patches for tables of number
> tend to always reject ;)

Agree, but textual strings are bad. I want to say :

if (error) {
	perror("RTNETLINK");
	return -1;
	}

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.

In that case you can keep the -EINVAL, the namespace won't be polluted,
and you can see what goes wrong. Agains this is that you need another
interface, which isn't portable.

>
> Textual error messages are e.g. used by plan9 and would be somewhat similar
> to /proc. It would probably waste a few bytes in the kernel, but that's not
> too bad, given the work it saves. e.g. rusty's code usually has a debug option
> that you can set and where each EINVAL outputs a error message; i always found
> that very useful and sometimes hacked that into other subsystems in my
> private tree.

Still means that all standard functions won't work.

> -Andi


	Igmar

-- 

--
Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 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 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 also bad for maintainers, because patches for tables of number
> > tend to always reject ;)
> 
> Agree, but textual strings are bad. I want to say :
> 
> if (error) {
> 	perror("RTNETLINK");
> 	return -1;
> 	}
> 
> 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, which each have own errors.

rtnetlink is such a radical interface for unix, adding a few more changes
for a different error reporting system probably does not make much difference.

my problem with keeping the textual error messages out of kernel is that
it means that three entities (kernel module, number table in kernel and 
external string table) need to be kept in sync. In practice that's usually
not the case.

David's /proc/errno_strings would only require keeping kernel table and
module in sync. 
Text errors for rtnetlink would localize it to the module itself. 
I could probably live with David's solution, although I would prefer the full
way. 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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, which each have own errors.

errno is only valid until a new syscall is done. So I don't see the
problem with multiple sockets, you can only perform one at a time.


> rtnetlink is such a radical interface for unix, adding a few more changes
> for a different error reporting system probably does not make much difference.
> 
> my problem with keeping the textual error messages out of kernel is that
> it means that three entities (kernel module, number table in kernel and 
> external string table) need to be kept in sync. In practice that's usually
> not the case.

I wonder if the glibc keeps it's own copy of the sys_errlist[]. If it has,
that means that we indeed have a problem..
Maybe the kernel could provide errno -> textual mapping, but that sounds
like bloat to me..

An other way is to have some kind of extended error.

> David's /proc/errno_strings would only require keeping kernel table and
> module in sync. 
> Text errors for rtnetlink would localize it to the module itself. 
> I could probably live with David's solution, although I would prefer the full
> way. 

Disadvantage of textual stuff is that you can't do more then print it. 

> -Andi


	Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 ridiculous than that?

/usr/src/linux/net/sched% grep EINVAL *.c | wc -l
    122


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 also bad for maintainers, because patches for tables of number 
 > tend to always reject ;) 

Fine, then no textual messages at all.

I cannot accept that an application writer goes through all the
trouble of using socket extended errors, watches for error returns
via this, and makes no attempt to understand what the different return
values mean.

People must be really suffering right now, and we ought to get
/proc/errno_strings implemented as soon as possible... :-)

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 in kernel space IMHO.

Thus the smiley in my original email.  I did not mean kernel errno
strings to be taken seriously at all.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 + iproute2

[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 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.



	Regards,

		Igmar
-- 

--
Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: i.palsenberg@jdimedia.nl
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/