Re: [PATCH] change ifmap.base_addr to u_long type
"David S. Miller" wrote: > >Date: Thu, 07 Sep 2000 17:35:22 -0700 >From: Jun Sun <[EMAIL PROTECTED]> > >Do we know exactly what userland apps/libs use ifmap? Maybe the >damage is not so bad, so that we can fix this problem without >making it look worse. > > It's a well established fixed kernel API, any app whatsoever can make > use of it. > > I advise you to stop trying to find ways to make your "quick and easy" > solution viable and work on the usable solution which will not break > userland. > David, You get my intension wrong. Actually I believe over the time it will destroy Linux if people keep introducing ifmap2 and ifmap3 and etc. My question was to find out if the problem is still in the stage where we can fix it cleanly, or it is already too late to do so - like many window's API. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
Date: Thu, 07 Sep 2000 17:35:22 -0700 From: Jun Sun <[EMAIL PROTECTED]> Do we know exactly what userland apps/libs use ifmap? Maybe the damage is not so bad, so that we can fix this problem without making it look worse. It's a well established fixed kernel API, any app whatsoever can make use of it. I advise you to stop trying to find ways to make your "quick and easy" solution viable and work on the usable solution which will not break userland. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
"David S. Miller" wrote: > >Date:Thu, 07 Sep 2000 14:36:02 -0700 >From: Jun Sun <[EMAIL PROTECTED]> > >Here is a small patch which is needed on non-i386 platforms. > > The layout of this structure is exported to userspace > applications, thus you cannot simply just change the > type in this structure to get the change you need. > > This change thus cannot be made as-is. > > You must find some other way, let me give you one example > of a potentially acceptable solution: > > 1) Add new member to union inside of ifreq where ifmap >currently lives. Add new member, perhaps called ifmap2 >which uses more appropriate types for base_addr member. > > 2) Add new ifreq call which looks at ifmap2 instead of ifmap. > > This way, existing userland applications still work as they > did before hand, and new ones can be written to use the ifmap2 > version of the interface. > > Also be sure that the glibc maintainers get this change once it > is in the kernel. > > Later, > David S. Miller > [EMAIL PROTECTED] Hmm, that is a whole lot more complicated than I thought. Do we know exactly what userland apps/libs use ifmap? Maybe the damage is not so bad, so that we can fix this problem without making it look worse. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
Date:Thu, 07 Sep 2000 14:36:02 -0700 From: Jun Sun <[EMAIL PROTECTED]> Here is a small patch which is needed on non-i386 platforms. The layout of this structure is exported to userspace applications, thus you cannot simply just change the type in this structure to get the change you need. This change thus cannot be made as-is. You must find some other way, let me give you one example of a potentially acceptable solution: 1) Add new member to union inside of ifreq where ifmap currently lives. Add new member, perhaps called ifmap2 which uses more appropriate types for base_addr member. 2) Add new ifreq call which looks at ifmap2 instead of ifmap. This way, existing userland applications still work as they did before hand, and new ones can be written to use the ifmap2 version of the interface. Also be sure that the glibc maintainers get this change once it is in the kernel. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
> Here is a small patch which is needed on non-i386 platforms. Which is wrong > ifmap.base_addr is mainly used to initialize net_device base_addr, which > is already a u_long. > > This change does not increase the memory size for struct ifmap. But does change the field offsets > In the same spirit, ifmap.irq should probably be changed to u_int as > well, but that would increase the size, and I don't have the need yet. > :-) Yep. You want to provide a new ioctl, but think about PCI multiple busses and the like and talk to DaveM before you think you have all the fields - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
Here is a small patch which is needed on non-i386 platforms. Which is wrong ifmap.base_addr is mainly used to initialize net_device base_addr, which is already a u_long. This change does not increase the memory size for struct ifmap. But does change the field offsets In the same spirit, ifmap.irq should probably be changed to u_int as well, but that would increase the size, and I don't have the need yet. :-) Yep. You want to provide a new ioctl, but think about PCI multiple busses and the like and talk to DaveM before you think you have all the fields - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
Date:Thu, 07 Sep 2000 14:36:02 -0700 From: Jun Sun [EMAIL PROTECTED] Here is a small patch which is needed on non-i386 platforms. The layout of this structure is exported to userspace applications, thus you cannot simply just change the type in this structure to get the change you need. This change thus cannot be made as-is. You must find some other way, let me give you one example of a potentially acceptable solution: 1) Add new member to union inside of ifreq where ifmap currently lives. Add new member, perhaps called ifmap2 which uses more appropriate types for base_addr member. 2) Add new ifreq call which looks at ifmap2 instead of ifmap. This way, existing userland applications still work as they did before hand, and new ones can be written to use the ifmap2 version of the interface. Also be sure that the glibc maintainers get this change once it is in the kernel. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
"David S. Miller" wrote: Date:Thu, 07 Sep 2000 14:36:02 -0700 From: Jun Sun [EMAIL PROTECTED] Here is a small patch which is needed on non-i386 platforms. The layout of this structure is exported to userspace applications, thus you cannot simply just change the type in this structure to get the change you need. This change thus cannot be made as-is. You must find some other way, let me give you one example of a potentially acceptable solution: 1) Add new member to union inside of ifreq where ifmap currently lives. Add new member, perhaps called ifmap2 which uses more appropriate types for base_addr member. 2) Add new ifreq call which looks at ifmap2 instead of ifmap. This way, existing userland applications still work as they did before hand, and new ones can be written to use the ifmap2 version of the interface. Also be sure that the glibc maintainers get this change once it is in the kernel. Later, David S. Miller [EMAIL PROTECTED] Hmm, that is a whole lot more complicated than I thought. Do we know exactly what userland apps/libs use ifmap? Maybe the damage is not so bad, so that we can fix this problem without making it look worse. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
Date: Thu, 07 Sep 2000 17:35:22 -0700 From: Jun Sun [EMAIL PROTECTED] Do we know exactly what userland apps/libs use ifmap? Maybe the damage is not so bad, so that we can fix this problem without making it look worse. It's a well established fixed kernel API, any app whatsoever can make use of it. I advise you to stop trying to find ways to make your "quick and easy" solution viable and work on the usable solution which will not break userland. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
"David S. Miller" wrote: Date: Thu, 07 Sep 2000 17:35:22 -0700 From: Jun Sun [EMAIL PROTECTED] Do we know exactly what userland apps/libs use ifmap? Maybe the damage is not so bad, so that we can fix this problem without making it look worse. It's a well established fixed kernel API, any app whatsoever can make use of it. I advise you to stop trying to find ways to make your "quick and easy" solution viable and work on the usable solution which will not break userland. David, You get my intension wrong. Actually I believe over the time it will destroy Linux if people keep introducing ifmap2 and ifmap3 and etc. My question was to find out if the problem is still in the stage where we can fix it cleanly, or it is already too late to do so - like many window's API. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
