Re: [RFC PATCH v1 14/31] ARC: syscall support
On Thursday 15 November 2012 06:05 PM, Arnd Bergmann wrote: > On Thursday 15 November 2012, Vineet Gupta wrote: >> So the primary concern here is not breaking the userspace ABI - right ? >> >> For syscalls I agree that we will indeed need to fix the ABI - by fixing >> uClibc. And if uClibc doesn't merge the fixes we can stay out of tree >> for uClibc - as we currently already are. > > I'm sure we can find a solution for uClibc. We already have seven > architectures using the generic syscalls, including at least one > (arm64) that is going to run on a large number of installations > in the future. > >> For gdbserver, the kernel provides the complete regset ABI. However it >> also provides a very limited version of old ABI - i.e. ptrace with >> PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the >> regset callbacks. This allows us to support the legacy gdbserver. If and >> when gdbserver upgrades it can switch over to new interface. So all >> along there will be NO ABI breakage at all. The cost is couple extra >> functions in kernel which we might have to maintain for some foreseeable >> future. Agree ? > > It's more a question of principle. The rule is that we don't break user > space, and ptrace is just another user space interface is this. If > we merge it now, we will keep it around forever, taking it out later > is not an option IMHO. My preference would be not to merge the backwards > compatibility layer for ptrace at all, but I'm willing to listen to > other people that support your view if you want to keep it. In one > way, ptrace is less critical than the other system calls, and that is > because it's already architecture specific. > > Arnd > OK as of now the legacy syscall ABI and ptrace PEEKUSR/POKEUSR are taken out of submissions tree - we'll carry these out-of-tree for sometime before eventually moving to newer uClibc/gdbserver which don't need these O-O-T patches. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Thursday 15 November 2012 06:05 PM, Arnd Bergmann wrote: On Thursday 15 November 2012, Vineet Gupta wrote: So the primary concern here is not breaking the userspace ABI - right ? For syscalls I agree that we will indeed need to fix the ABI - by fixing uClibc. And if uClibc doesn't merge the fixes we can stay out of tree for uClibc - as we currently already are. I'm sure we can find a solution for uClibc. We already have seven architectures using the generic syscalls, including at least one (arm64) that is going to run on a large number of installations in the future. For gdbserver, the kernel provides the complete regset ABI. However it also provides a very limited version of old ABI - i.e. ptrace with PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the regset callbacks. This allows us to support the legacy gdbserver. If and when gdbserver upgrades it can switch over to new interface. So all along there will be NO ABI breakage at all. The cost is couple extra functions in kernel which we might have to maintain for some foreseeable future. Agree ? It's more a question of principle. The rule is that we don't break user space, and ptrace is just another user space interface is this. If we merge it now, we will keep it around forever, taking it out later is not an option IMHO. My preference would be not to merge the backwards compatibility layer for ptrace at all, but I'm willing to listen to other people that support your view if you want to keep it. In one way, ptrace is less critical than the other system calls, and that is because it's already architecture specific. Arnd OK as of now the legacy syscall ABI and ptrace PEEKUSR/POKEUSR are taken out of submissions tree - we'll carry these out-of-tree for sometime before eventually moving to newer uClibc/gdbserver which don't need these O-O-T patches. -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Thursday 15 November 2012, Vineet Gupta wrote: > So the primary concern here is not breaking the userspace ABI - right ? > > For syscalls I agree that we will indeed need to fix the ABI - by fixing > uClibc. And if uClibc doesn't merge the fixes we can stay out of tree > for uClibc - as we currently already are. I'm sure we can find a solution for uClibc. We already have seven architectures using the generic syscalls, including at least one (arm64) that is going to run on a large number of installations in the future. > For gdbserver, the kernel provides the complete regset ABI. However it > also provides a very limited version of old ABI - i.e. ptrace with > PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the > regset callbacks. This allows us to support the legacy gdbserver. If and > when gdbserver upgrades it can switch over to new interface. So all > along there will be NO ABI breakage at all. The cost is couple extra > functions in kernel which we might have to maintain for some foreseeable > future. Agree ? It's more a question of principle. The rule is that we don't break user space, and ptrace is just another user space interface is this. If we merge it now, we will keep it around forever, taking it out later is not an option IMHO. My preference would be not to merge the backwards compatibility layer for ptrace at all, but I'm willing to listen to other people that support your view if you want to keep it. In one way, ptrace is less critical than the other system calls, and that is because it's already architecture specific. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Thursday 15 November 2012, Vineet Gupta wrote: So the primary concern here is not breaking the userspace ABI - right ? For syscalls I agree that we will indeed need to fix the ABI - by fixing uClibc. And if uClibc doesn't merge the fixes we can stay out of tree for uClibc - as we currently already are. I'm sure we can find a solution for uClibc. We already have seven architectures using the generic syscalls, including at least one (arm64) that is going to run on a large number of installations in the future. For gdbserver, the kernel provides the complete regset ABI. However it also provides a very limited version of old ABI - i.e. ptrace with PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the regset callbacks. This allows us to support the legacy gdbserver. If and when gdbserver upgrades it can switch over to new interface. So all along there will be NO ABI breakage at all. The cost is couple extra functions in kernel which we might have to maintain for some foreseeable future. Agree ? It's more a question of principle. The rule is that we don't break user space, and ptrace is just another user space interface is this. If we merge it now, we will keep it around forever, taking it out later is not an option IMHO. My preference would be not to merge the backwards compatibility layer for ptrace at all, but I'm willing to listen to other people that support your view if you want to keep it. In one way, ptrace is less critical than the other system calls, and that is because it's already architecture specific. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Tuesday 13 November 2012 04:07 PM, Arnd Bergmann wrote: > On Tuesday 13 November 2012, Gilad Ben-Yossef wrote: >> So, I completely agree about not adding more deprecated system call or >> ABIs (thinking about the ptrace regset issues in another patch in the >> same patchset), but on the other hand I have to wonder if having a >> port in the tree that doesn't have a working C library or a debugger >> makes sense. >> >> I mean, it is not quite the same thing as saying: "well, users of the >> old versions of the user tools will need to maintain out of tree >> patches". That makes sense - it puts the burden of maintenance on >> people clinging to new versions when newer one exists, but this is not >> what is happening with Arc. Right now, there are no working version of >> the tools for Arc, so everyone will need to use the out of tree >> patches. >> >> I wonder what is worse - having an in tree port that no one (can) use >> or adding some deprecated crap (sorry...), clearly marked for deletion >> the minute a version of the relevant user tools exists that can be >> used with the new mechanisms? > The point is that all existing users already need to rebuild all their > user space since the upstream version is using the generic system call > numbers. What I want to avoid is breaking everything twice, and the most > logical point to do that is when moving from an out-of-tree kernel fork > to the mainline version. I completely agree. > If mainline doesn't work for you yet, the most logical choice is to > stay on whatever kernel you have working right now, and only change > over to the upstream version once it works with an ABI that we want > to maintain in the long term. Obviously I can't stop from using a > mix of the two while you are waiting for (or working on) getting > gdb and uclibc supported with the new interface, but my recommendation > is not to ship that in products to end-users that would suffer > from another ABI change later on. > > What I'm trying to enforce here is that the upstream version follows > the exact same rules that we apply to all other ports, which is > that we don't break existing user space that was running with an > older upstream kernel. So the primary concern here is not breaking the userspace ABI - right ? For syscalls I agree that we will indeed need to fix the ABI - by fixing uClibc. And if uClibc doesn't merge the fixes we can stay out of tree for uClibc - as we currently already are. For gdbserver, the kernel provides the complete regset ABI. However it also provides a very limited version of old ABI - i.e. ptrace with PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the regset callbacks. This allows us to support the legacy gdbserver. If and when gdbserver upgrades it can switch over to new interface. So all along there will be NO ABI breakage at all. The cost is couple extra functions in kernel which we might have to maintain for some foreseeable future. Agree ? -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 14/11/12 12:23, Arnd Bergmann wrote: > On Tuesday 13 November 2012, James Hogan wrote: >> Hopefully with several architecture maintainers asking for this it might >> get somewhere, but indeed we're aware of the feedback problem on that list. >> >> The points that I've considered for defaulting to old syscalls: >> * doesn't change existing behaviour of other architectures, so is simply >> less risk of breaking them. >> * could possibly make uClibc slightly smaller if it doesn't have to add >> extra arguments. > > The second argument is not very good when you consider that it means adding > the same wrapper into the kernel rather than into uClibc, where it can > be stripped out when unused (e.g. for static compilation) and doesn't > have to be present in memory since the library is in pageable user space > memory, while the kernel side implementation would always have to > present. The context is existing architectures which already have to support the deprecated syscalls pretty much forever (in addition to the new ones), and therefore can't strip out the kernel side implementation anyway. I don't see any of these arguments (either way) as holding too much weight to be honest though. Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Tuesday 13 November 2012, James Hogan wrote: > Hopefully with several architecture maintainers asking for this it might > get somewhere, but indeed we're aware of the feedback problem on that list. > > The points that I've considered for defaulting to old syscalls: > * doesn't change existing behaviour of other architectures, so is simply > less risk of breaking them. > * could possibly make uClibc slightly smaller if it doesn't have to add > extra arguments. The second argument is not very good when you consider that it means adding the same wrapper into the kernel rather than into uClibc, where it can be stripped out when unused (e.g. for static compilation) and doesn't have to be present in memory since the library is in pageable user space memory, while the kernel side implementation would always have to present. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Tuesday 13 November 2012, James Hogan wrote: Hopefully with several architecture maintainers asking for this it might get somewhere, but indeed we're aware of the feedback problem on that list. The points that I've considered for defaulting to old syscalls: * doesn't change existing behaviour of other architectures, so is simply less risk of breaking them. * could possibly make uClibc slightly smaller if it doesn't have to add extra arguments. The second argument is not very good when you consider that it means adding the same wrapper into the kernel rather than into uClibc, where it can be stripped out when unused (e.g. for static compilation) and doesn't have to be present in memory since the library is in pageable user space memory, while the kernel side implementation would always have to present. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 14/11/12 12:23, Arnd Bergmann wrote: On Tuesday 13 November 2012, James Hogan wrote: Hopefully with several architecture maintainers asking for this it might get somewhere, but indeed we're aware of the feedback problem on that list. The points that I've considered for defaulting to old syscalls: * doesn't change existing behaviour of other architectures, so is simply less risk of breaking them. * could possibly make uClibc slightly smaller if it doesn't have to add extra arguments. The second argument is not very good when you consider that it means adding the same wrapper into the kernel rather than into uClibc, where it can be stripped out when unused (e.g. for static compilation) and doesn't have to be present in memory since the library is in pageable user space memory, while the kernel side implementation would always have to present. The context is existing architectures which already have to support the deprecated syscalls pretty much forever (in addition to the new ones), and therefore can't strip out the kernel side implementation anyway. I don't see any of these arguments (either way) as holding too much weight to be honest though. Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Tuesday 13 November 2012 04:07 PM, Arnd Bergmann wrote: On Tuesday 13 November 2012, Gilad Ben-Yossef wrote: So, I completely agree about not adding more deprecated system call or ABIs (thinking about the ptrace regset issues in another patch in the same patchset), but on the other hand I have to wonder if having a port in the tree that doesn't have a working C library or a debugger makes sense. I mean, it is not quite the same thing as saying: well, users of the old versions of the user tools will need to maintain out of tree patches. That makes sense - it puts the burden of maintenance on people clinging to new versions when newer one exists, but this is not what is happening with Arc. Right now, there are no working version of the tools for Arc, so everyone will need to use the out of tree patches. I wonder what is worse - having an in tree port that no one (can) use or adding some deprecated crap (sorry...), clearly marked for deletion the minute a version of the relevant user tools exists that can be used with the new mechanisms? The point is that all existing users already need to rebuild all their user space since the upstream version is using the generic system call numbers. What I want to avoid is breaking everything twice, and the most logical point to do that is when moving from an out-of-tree kernel fork to the mainline version. I completely agree. If mainline doesn't work for you yet, the most logical choice is to stay on whatever kernel you have working right now, and only change over to the upstream version once it works with an ABI that we want to maintain in the long term. Obviously I can't stop from using a mix of the two while you are waiting for (or working on) getting gdb and uclibc supported with the new interface, but my recommendation is not to ship that in products to end-users that would suffer from another ABI change later on. What I'm trying to enforce here is that the upstream version follows the exact same rules that we apply to all other ports, which is that we don't break existing user space that was running with an older upstream kernel. So the primary concern here is not breaking the userspace ABI - right ? For syscalls I agree that we will indeed need to fix the ABI - by fixing uClibc. And if uClibc doesn't merge the fixes we can stay out of tree for uClibc - as we currently already are. For gdbserver, the kernel provides the complete regset ABI. However it also provides a very limited version of old ABI - i.e. ptrace with PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the regset callbacks. This allows us to support the legacy gdbserver. If and when gdbserver upgrades it can switch over to new interface. So all along there will be NO ABI breakage at all. The cost is couple extra functions in kernel which we might have to maintain for some foreseeable future. Agree ? -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 13/11/12 12:01, Jonas Bonn wrote: > On 13 November 2012 12:41, James Hogan wrote: >> The uClibc patches I mentioned have been posted, see here: >> >> http://lists.busybox.net/pipermail/uclibc/2012-November/047110.html >> >> Please do try them out and provide any feedback. >> > > Hi James, > > Many thanks for picking this up... > > This is the third time around for trying to get this into uClibc as > Mark Salter also pushed a patch set which got about as much feedback > (almost none) on the list as mine did. His patchset, like yours, > preferred the "old" syscalls when present. > > ...and that gets me around to the question: why should the "old" > syscalls be preferred? I'm specifically asking this here because I'm > curious what the kernel developers' take on this is. Hi Jonas, Hopefully with several architecture maintainers asking for this it might get somewhere, but indeed we're aware of the feedback problem on that list. The points that I've considered for defaulting to old syscalls: * doesn't change existing behaviour of other architectures, so is simply less risk of breaking them. * could possibly make uClibc slightly smaller if it doesn't have to add extra arguments. against: * if defaulted to new syscalls, could give customers a chance to rebuild their libc so that when deprecated syscalls are removed they don't notice. Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 13 November 2012 12:41, James Hogan wrote: > The uClibc patches I mentioned have been posted, see here: > > http://lists.busybox.net/pipermail/uclibc/2012-November/047110.html > > Please do try them out and provide any feedback. > Hi James, Many thanks for picking this up... This is the third time around for trying to get this into uClibc as Mark Salter also pushed a patch set which got about as much feedback (almost none) on the list as mine did. His patchset, like yours, preferred the "old" syscalls when present. ...and that gets me around to the question: why should the "old" syscalls be preferred? I'm specifically asking this here because I'm curious what the kernel developers' take on this is. Regards, Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 09/11/12 09:50, James Hogan wrote: > On 07/11/12 14:21, Arnd Bergmann wrote: >> On Wednesday 07 November 2012, Vineet Gupta wrote: >>> + * Being uClibc based we need some of the deprecated syscalls: >>> + * -Not emulated by uClibc at all >>> + * unlink, mkdir,... (needed by Busybox, LTP etc) >>> + * times (needed by LTP pan test harness) >>> + * -Not emulated efficiently >>> + * select: emulated using pselect (but extra code to chk usec > 1sec) >>> + * >>> + * some (send/recv) correctly emulated using (recfrom/sendto) and >>> + * some arch specific ones (fork/vfork)can easily be emulated using clone >>> but >>> + * thats the price of using common-denominator >>> + */ >>> +#define __ARCH_WANT_SYSCALL_NO_AT >>> +#define __ARCH_WANT_SYSCALL_NO_FLAGS >>> +#define __ARCH_WANT_SYSCALL_OFF_T >>> +#define __ARCH_WANT_SYSCALL_DEPRECATED >> >> I'm pretty sure that this has been solved before, best get in contact with >> the maintainers of the openrisc/c6x/hexagon platforms, that probably all >> use uClibc without needing these. >> >> You have to remove the legacy calls here. > FYI, we'll soon be making some uClibc patches available so that it can > work without these deprecated syscalls and with the newer IPC interface > (the work was needed for metag too). It's based roughly on the OpenRisc > patches from last year, but with a fair few changes. Hi Vineet, The uClibc patches I mentioned have been posted, see here: http://lists.busybox.net/pipermail/uclibc/2012-November/047110.html Please do try them out and provide any feedback. Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Tuesday 13 November 2012, Gilad Ben-Yossef wrote: > So, I completely agree about not adding more deprecated system call or > ABIs (thinking about the ptrace regset issues in another patch in the > same patchset), but on the other hand I have to wonder if having a > port in the tree that doesn't have a working C library or a debugger > makes sense. > > I mean, it is not quite the same thing as saying: "well, users of the > old versions of the user tools will need to maintain out of tree > patches". That makes sense - it puts the burden of maintenance on > people clinging to new versions when newer one exists, but this is not > what is happening with Arc. Right now, there are no working version of > the tools for Arc, so everyone will need to use the out of tree > patches. > > I wonder what is worse - having an in tree port that no one (can) use > or adding some deprecated crap (sorry...), clearly marked for deletion > the minute a version of the relevant user tools exists that can be > used with the new mechanisms? The point is that all existing users already need to rebuild all their user space since the upstream version is using the generic system call numbers. What I want to avoid is breaking everything twice, and the most logical point to do that is when moving from an out-of-tree kernel fork to the mainline version. If mainline doesn't work for you yet, the most logical choice is to stay on whatever kernel you have working right now, and only change over to the upstream version once it works with an ABI that we want to maintain in the long term. Obviously I can't stop from using a mix of the two while you are waiting for (or working on) getting gdb and uclibc supported with the new interface, but my recommendation is not to ship that in products to end-users that would suffer from another ABI change later on. What I'm trying to enforce here is that the upstream version follows the exact same rules that we apply to all other ports, which is that we don't break existing user space that was running with an older upstream kernel. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Wed, Nov 7, 2012 at 4:21 PM, Arnd Bergmann wrote: > On Wednesday 07 November 2012, Vineet Gupta wrote: >> + * Being uClibc based we need some of the deprecated syscalls: >> + * -Not emulated by uClibc at all >> + * unlink, mkdir,... (needed by Busybox, LTP etc) >> + * times (needed by LTP pan test harness) >> + * -Not emulated efficiently >> + * select: emulated using pselect (but extra code to chk usec > 1sec) >> + * > ... > I'm pretty sure that this has been solved before, best get in contact with > the maintainers of the openrisc/c6x/hexagon platforms, that probably all > use uClibc without needing these. > > You have to remove the legacy calls here. So, I completely agree about not adding more deprecated system call or ABIs (thinking about the ptrace regset issues in another patch in the same patchset), but on the other hand I have to wonder if having a port in the tree that doesn't have a working C library or a debugger makes sense. I mean, it is not quite the same thing as saying: "well, users of the old versions of the user tools will need to maintain out of tree patches". That makes sense - it puts the burden of maintenance on people clinging to new versions when newer one exists, but this is not what is happening with Arc. Right now, there are no working version of the tools for Arc, so everyone will need to use the out of tree patches. I wonder what is worse - having an in tree port that no one (can) use or adding some deprecated crap (sorry...), clearly marked for deletion the minute a version of the relevant user tools exists that can be used with the new mechanisms? Just my 2c as an Arc kernel port user, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker gi...@benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Wed, Nov 7, 2012 at 4:21 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 07 November 2012, Vineet Gupta wrote: + * Being uClibc based we need some of the deprecated syscalls: + * -Not emulated by uClibc at all + * unlink, mkdir,... (needed by Busybox, LTP etc) + * times (needed by LTP pan test harness) + * -Not emulated efficiently + * select: emulated using pselect (but extra code to chk usec 1sec) + * ... I'm pretty sure that this has been solved before, best get in contact with the maintainers of the openrisc/c6x/hexagon platforms, that probably all use uClibc without needing these. You have to remove the legacy calls here. So, I completely agree about not adding more deprecated system call or ABIs (thinking about the ptrace regset issues in another patch in the same patchset), but on the other hand I have to wonder if having a port in the tree that doesn't have a working C library or a debugger makes sense. I mean, it is not quite the same thing as saying: well, users of the old versions of the user tools will need to maintain out of tree patches. That makes sense - it puts the burden of maintenance on people clinging to new versions when newer one exists, but this is not what is happening with Arc. Right now, there are no working version of the tools for Arc, so everyone will need to use the out of tree patches. I wonder what is worse - having an in tree port that no one (can) use or adding some deprecated crap (sorry...), clearly marked for deletion the minute a version of the relevant user tools exists that can be used with the new mechanisms? Just my 2c as an Arc kernel port user, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker gi...@benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog? -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Tuesday 13 November 2012, Gilad Ben-Yossef wrote: So, I completely agree about not adding more deprecated system call or ABIs (thinking about the ptrace regset issues in another patch in the same patchset), but on the other hand I have to wonder if having a port in the tree that doesn't have a working C library or a debugger makes sense. I mean, it is not quite the same thing as saying: well, users of the old versions of the user tools will need to maintain out of tree patches. That makes sense - it puts the burden of maintenance on people clinging to new versions when newer one exists, but this is not what is happening with Arc. Right now, there are no working version of the tools for Arc, so everyone will need to use the out of tree patches. I wonder what is worse - having an in tree port that no one (can) use or adding some deprecated crap (sorry...), clearly marked for deletion the minute a version of the relevant user tools exists that can be used with the new mechanisms? The point is that all existing users already need to rebuild all their user space since the upstream version is using the generic system call numbers. What I want to avoid is breaking everything twice, and the most logical point to do that is when moving from an out-of-tree kernel fork to the mainline version. If mainline doesn't work for you yet, the most logical choice is to stay on whatever kernel you have working right now, and only change over to the upstream version once it works with an ABI that we want to maintain in the long term. Obviously I can't stop from using a mix of the two while you are waiting for (or working on) getting gdb and uclibc supported with the new interface, but my recommendation is not to ship that in products to end-users that would suffer from another ABI change later on. What I'm trying to enforce here is that the upstream version follows the exact same rules that we apply to all other ports, which is that we don't break existing user space that was running with an older upstream kernel. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 09/11/12 09:50, James Hogan wrote: On 07/11/12 14:21, Arnd Bergmann wrote: On Wednesday 07 November 2012, Vineet Gupta wrote: + * Being uClibc based we need some of the deprecated syscalls: + * -Not emulated by uClibc at all + * unlink, mkdir,... (needed by Busybox, LTP etc) + * times (needed by LTP pan test harness) + * -Not emulated efficiently + * select: emulated using pselect (but extra code to chk usec 1sec) + * + * some (send/recv) correctly emulated using (recfrom/sendto) and + * some arch specific ones (fork/vfork)can easily be emulated using clone but + * thats the price of using common-denominator + */ +#define __ARCH_WANT_SYSCALL_NO_AT +#define __ARCH_WANT_SYSCALL_NO_FLAGS +#define __ARCH_WANT_SYSCALL_OFF_T +#define __ARCH_WANT_SYSCALL_DEPRECATED I'm pretty sure that this has been solved before, best get in contact with the maintainers of the openrisc/c6x/hexagon platforms, that probably all use uClibc without needing these. You have to remove the legacy calls here. FYI, we'll soon be making some uClibc patches available so that it can work without these deprecated syscalls and with the newer IPC interface (the work was needed for metag too). It's based roughly on the OpenRisc patches from last year, but with a fair few changes. Hi Vineet, The uClibc patches I mentioned have been posted, see here: http://lists.busybox.net/pipermail/uclibc/2012-November/047110.html Please do try them out and provide any feedback. Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 13 November 2012 12:41, James Hogan james.ho...@imgtec.com wrote: The uClibc patches I mentioned have been posted, see here: http://lists.busybox.net/pipermail/uclibc/2012-November/047110.html Please do try them out and provide any feedback. Hi James, Many thanks for picking this up... This is the third time around for trying to get this into uClibc as Mark Salter also pushed a patch set which got about as much feedback (almost none) on the list as mine did. His patchset, like yours, preferred the old syscalls when present. ...and that gets me around to the question: why should the old syscalls be preferred? I'm specifically asking this here because I'm curious what the kernel developers' take on this is. Regards, Jonas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 13/11/12 12:01, Jonas Bonn wrote: On 13 November 2012 12:41, James Hogan james.ho...@imgtec.com wrote: The uClibc patches I mentioned have been posted, see here: http://lists.busybox.net/pipermail/uclibc/2012-November/047110.html Please do try them out and provide any feedback. Hi James, Many thanks for picking this up... This is the third time around for trying to get this into uClibc as Mark Salter also pushed a patch set which got about as much feedback (almost none) on the list as mine did. His patchset, like yours, preferred the old syscalls when present. ...and that gets me around to the question: why should the old syscalls be preferred? I'm specifically asking this here because I'm curious what the kernel developers' take on this is. Hi Jonas, Hopefully with several architecture maintainers asking for this it might get somewhere, but indeed we're aware of the feedback problem on that list. The points that I've considered for defaulting to old syscalls: * doesn't change existing behaviour of other architectures, so is simply less risk of breaking them. * could possibly make uClibc slightly smaller if it doesn't have to add extra arguments. against: * if defaulted to new syscalls, could give customers a chance to rebuild their libc so that when deprecated syscalls are removed they don't notice. Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 07/11/12 14:21, Arnd Bergmann wrote: > On Wednesday 07 November 2012, Vineet Gupta wrote: >> + * Being uClibc based we need some of the deprecated syscalls: >> + * -Not emulated by uClibc at all >> + * unlink, mkdir,... (needed by Busybox, LTP etc) >> + * times (needed by LTP pan test harness) >> + * -Not emulated efficiently >> + * select: emulated using pselect (but extra code to chk usec > 1sec) >> + * >> + * some (send/recv) correctly emulated using (recfrom/sendto) and >> + * some arch specific ones (fork/vfork)can easily be emulated using clone >> but >> + * thats the price of using common-denominator >> + */ >> +#define __ARCH_WANT_SYSCALL_NO_AT >> +#define __ARCH_WANT_SYSCALL_NO_FLAGS >> +#define __ARCH_WANT_SYSCALL_OFF_T >> +#define __ARCH_WANT_SYSCALL_DEPRECATED > > I'm pretty sure that this has been solved before, best get in contact with > the maintainers of the openrisc/c6x/hexagon platforms, that probably all > use uClibc without needing these. > > You have to remove the legacy calls here. Hi Vineet, FYI, we'll soon be making some uClibc patches available so that it can work without these deprecated syscalls and with the newer IPC interface (the work was needed for metag too). It's based roughly on the OpenRisc patches from last year, but with a fair few changes. Thanks James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 07/11/12 14:21, Arnd Bergmann wrote: On Wednesday 07 November 2012, Vineet Gupta wrote: + * Being uClibc based we need some of the deprecated syscalls: + * -Not emulated by uClibc at all + * unlink, mkdir,... (needed by Busybox, LTP etc) + * times (needed by LTP pan test harness) + * -Not emulated efficiently + * select: emulated using pselect (but extra code to chk usec 1sec) + * + * some (send/recv) correctly emulated using (recfrom/sendto) and + * some arch specific ones (fork/vfork)can easily be emulated using clone but + * thats the price of using common-denominator + */ +#define __ARCH_WANT_SYSCALL_NO_AT +#define __ARCH_WANT_SYSCALL_NO_FLAGS +#define __ARCH_WANT_SYSCALL_OFF_T +#define __ARCH_WANT_SYSCALL_DEPRECATED I'm pretty sure that this has been solved before, best get in contact with the maintainers of the openrisc/c6x/hexagon platforms, that probably all use uClibc without needing these. You have to remove the legacy calls here. Hi Vineet, FYI, we'll soon be making some uClibc patches available so that it can work without these deprecated syscalls and with the newer IPC interface (the work was needed for metag too). It's based roughly on the OpenRisc patches from last year, but with a fair few changes. Thanks James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Wednesday 07 November 2012, Vineet Gupta wrote: > + * Being uClibc based we need some of the deprecated syscalls: > + * -Not emulated by uClibc at all > + * unlink, mkdir,... (needed by Busybox, LTP etc) > + * times (needed by LTP pan test harness) > + * -Not emulated efficiently > + * select: emulated using pselect (but extra code to chk usec > 1sec) > + * > + * some (send/recv) correctly emulated using (recfrom/sendto) and > + * some arch specific ones (fork/vfork)can easily be emulated using clone but > + * thats the price of using common-denominator > + */ > +#define __ARCH_WANT_SYSCALL_NO_AT > +#define __ARCH_WANT_SYSCALL_NO_FLAGS > +#define __ARCH_WANT_SYSCALL_OFF_T > +#define __ARCH_WANT_SYSCALL_DEPRECATED I'm pretty sure that this has been solved before, best get in contact with the maintainers of the openrisc/c6x/hexagon platforms, that probably all use uClibc without needing these. You have to remove the legacy calls here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On Wednesday 07 November 2012, Vineet Gupta wrote: + * Being uClibc based we need some of the deprecated syscalls: + * -Not emulated by uClibc at all + * unlink, mkdir,... (needed by Busybox, LTP etc) + * times (needed by LTP pan test harness) + * -Not emulated efficiently + * select: emulated using pselect (but extra code to chk usec 1sec) + * + * some (send/recv) correctly emulated using (recfrom/sendto) and + * some arch specific ones (fork/vfork)can easily be emulated using clone but + * thats the price of using common-denominator + */ +#define __ARCH_WANT_SYSCALL_NO_AT +#define __ARCH_WANT_SYSCALL_NO_FLAGS +#define __ARCH_WANT_SYSCALL_OFF_T +#define __ARCH_WANT_SYSCALL_DEPRECATED I'm pretty sure that this has been solved before, best get in contact with the maintainers of the openrisc/c6x/hexagon platforms, that probably all use uClibc without needing these. You have to remove the legacy calls here. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
