Re: Is it useful to support user level drivers
"Richard B. Johnson" wrote: > > It just broke. The handler returned before the cause of the interrupt > was handled. Think LEVEL interrupts. The same interrupt will again > be entered, looping over and over again, until the tiny bit if CPU > resource available for the few instants the handler was not in the > ISR, was enough for the user-mode signal-handler to shut the > damn thing off, pull the plug, and figure this will never work. Sorry, I've missed an action writing the previous message (now marked with a +) Kernel space: - irq 9 arrives from our device - interrupts are disabled - our kernel space micro handler is invoked - interrupt source is checked + interrupt is acknowledged to our device - if no notification is pending a signal is notificated for user space (or a process is marked runnable) - optionally our device interrupt generation is disabled - handler returns - interrupts are enabled > > > > User space: > > - signal arrive (or process is restarted) > > - action is done > > - notification is acknowledged (using an ioctl) > > > > Way too late see above. Don't equivocate me: this not the IRQ acknowledge, it's the acknowledge of the user space notification. Also note that this mechanism is not an attempt to demonstrate that to move interrupt handlers to user space is a good thing. I wanted only to show a way to permit to have *pseudo* interrupt handlers in user space also having shared IRQ. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Alan Cox wrote: > > > (i.e. counted). An alternative to queuing (user selectable) is to block > > interrupt generation at hardware level in kernel space immediately > > before notification. > > > > I'm missing something? > > IRQ 9 shared between user space app and disk. IRQ arrives is disabled and > reported, app wakes up, app wants to page in code, IRQ is disabled, box dies > > You have to handle that in kernel space, at least enough to handle the > irq event, ack it and queue the data I try to be more clear: Kernel space: - irq 9 arrives from our device - interrupts are disabled - our kernel space micro handler is invoked - interrupt source is checked - if no notification is pending a signal is notificated for user space (or a process is marked runnable) - optionally our device interrupt generation is disabled - handler returns - interrupts are enabled User space: - signal arrive (or process is restarted) - action is done - notification is acknowledged (using an ioctl) Kernel space: - if we have other notifications to do, do one - optionally our device interrupt generation is reenabled -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"Dmitry A. Fedorov" wrote: > > On Thu, 21 Jun 2001, Oliver Neukum wrote: > > > > Lastly an IRQ kernel module can disable_irq() from interrupt handler > > > and enable it again only on explicit acknowledge from user. > > > > Unless you need that interrupt to be enabled to deliver the signal or let > > Need not. Signal and other event delivery mechanisms has nothing > common with disable/enable_irq(). > > > userspace reenable the interrupt. > > "user acknowledge" is mean that. > > > In addition, how do you handle shared interrupts ? > > It is impossible, see my another message. I don't see why you think it's impossible, the only thing you need is that your kernel module know how to discriminate the interrupt source. You can do this also with a irq.o module and other tiny modules that register their irq source detection code. Then you have /dev/irqX with the following API: - ioctl(fd, IRQ_SUBSCRIBE, source_id); - ioctl(fd, IRQ_ACK, source_id); - poll - async notification Interrupts received between notification and acknowledge are queued (i.e. counted). An alternative to queuing (user selectable) is to block interrupt generation at hardware level in kernel space immediately before notification. I'm missing something? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Dmitry A. Fedorov wrote: On Thu, 21 Jun 2001, Oliver Neukum wrote: Lastly an IRQ kernel module can disable_irq() from interrupt handler and enable it again only on explicit acknowledge from user. Unless you need that interrupt to be enabled to deliver the signal or let Need not. Signal and other event delivery mechanisms has nothing common with disable/enable_irq(). userspace reenable the interrupt. user acknowledge is mean that. In addition, how do you handle shared interrupts ? It is impossible, see my another message. I don't see why you think it's impossible, the only thing you need is that your kernel module know how to discriminate the interrupt source. You can do this also with a irq.o module and other tiny modules that register their irq source detection code. Then you have /dev/irqX with the following API: - ioctl(fd, IRQ_SUBSCRIBE, source_id); - ioctl(fd, IRQ_ACK, source_id); - poll - async notification Interrupts received between notification and acknowledge are queued (i.e. counted). An alternative to queuing (user selectable) is to block interrupt generation at hardware level in kernel space immediately before notification. I'm missing something? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Alan Cox wrote: (i.e. counted). An alternative to queuing (user selectable) is to block interrupt generation at hardware level in kernel space immediately before notification. I'm missing something? IRQ 9 shared between user space app and disk. IRQ arrives is disabled and reported, app wakes up, app wants to page in code, IRQ is disabled, box dies You have to handle that in kernel space, at least enough to handle the irq event, ack it and queue the data I try to be more clear: Kernel space: - irq 9 arrives from our device - interrupts are disabled - our kernel space micro handler is invoked - interrupt source is checked - if no notification is pending a signal is notificated for user space (or a process is marked runnable) - optionally our device interrupt generation is disabled - handler returns - interrupts are enabled User space: - signal arrive (or process is restarted) - action is done - notification is acknowledged (using an ioctl) Kernel space: - if we have other notifications to do, do one - optionally our device interrupt generation is reenabled -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Richard B. Johnson wrote: It just broke. The handler returned before the cause of the interrupt was handled. Think LEVEL interrupts. The same interrupt will again be entered, looping over and over again, until the tiny bit if CPU resource available for the few instants the handler was not in the ISR, was enough for the user-mode signal-handler to shut the damn thing off, pull the plug, and figure this will never work. Sorry, I've missed an action writing the previous message (now marked with a +) Kernel space: - irq 9 arrives from our device - interrupts are disabled - our kernel space micro handler is invoked - interrupt source is checked + interrupt is acknowledged to our device - if no notification is pending a signal is notificated for user space (or a process is marked runnable) - optionally our device interrupt generation is disabled - handler returns - interrupts are enabled User space: - signal arrive (or process is restarted) - action is done - notification is acknowledged (using an ioctl) Way too late see above. Don't equivocate me: this not the IRQ acknowledge, it's the acknowledge of the user space notification. Also note that this mechanism is not an attempt to demonstrate that to move interrupt handlers to user space is a good thing. I wanted only to show a way to permit to have *pseudo* interrupt handlers in user space also having shared IRQ. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
Zach Brown wrote: > > > I now have a patch that will output the hwv buttons pressed (up, > > down, mute) to a new dynamically allocated misc device as letters > > u, d, m, instead of directly modifying the mixer. Anyone want > > that? It's more flexible than either the patch that's currently > > in -ac or Lukas's patch, but you need a little userspace daemon > > for it to do anything useful. > > hmm.. how do the alsa guys deal with hw volume? I'm not sure I like > adding more stuff to the OSS API. It's a control separated from master volume. Often there is another control that control if the two are linked. Application may ask notification for controls changes (like the hw volume one). This imply that an interrupt is related to this event. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
Zach Brown wrote: I now have a patch that will output the hwv buttons pressed (up, down, mute) to a new dynamically allocated misc device as letters u, d, m, instead of directly modifying the mixer. Anyone want that? It's more flexible than either the patch that's currently in -ac or Lukas's patch, but you need a little userspace daemon for it to do anything useful. hmm.. how do the alsa guys deal with hw volume? I'm not sure I like adding more stuff to the OSS API. It's a control separated from master volume. Often there is another control that control if the two are linked. Application may ask notification for controls changes (like the hw volume one). This imply that an interrupt is related to this event. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
Adrian Bunk wrote: > > Hi, > > while looking for the reason of a build failure of the ALSA libraries on > ARM [1] I discovered the following strange thing: > > On some architectures a function is inside an "#ifdef __KERNEL__" in the > header file and on others not. Is there a reason for this or is this > inconsistency simply a bug? This is a bug on some architectures, I've personally fixed this on PPC sending a patch to Cort Dougan. It has been included in 2.4.5. I'd like you send a patch to maintainers (or perhaps to Alan). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent #ifdef __KERNEL__ on different architectures
Adrian Bunk wrote: Hi, while looking for the reason of a build failure of the ALSA libraries on ARM [1] I discovered the following strange thing: On some architectures a function is inside an #ifdef __KERNEL__ in the header file and on others not. Is there a reason for this or is this inconsistency simply a bug? This is a bug on some architectures, I've personally fixed this on PPC sending a patch to Cort Dougan. It has been included in 2.4.5. I'd like you send a patch to maintainers (or perhaps to Alan). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: > > On Sun, 20 May 2001, Abramo Bagnara wrote: > > > > Face it, we _already_ have more than one side band. > > > > This does not imply it's necessarily a good idea. > > We are comparing > > > > echo "9600" > /proc/self/fd/0/speed (or /dev/ttyS0/speed) > > echo "8" > /proc/self/fd/0/bits (or /dev/ttyS0/bits) > > > > with > > > > echo -e "speed 9600\nbits 8" > /proc/self/fd/0/ioctl (or > > /dev/ttyS0/ioctl). > > How about reading from them? You are forcing restriction that may make > sense in some cases, but doesn't look good for everything. exec 3>/dev/ttyS0/ioctl exec 4<&3 echo "speed" >&3 cat <&4 exec 3>&- exec 4<&- Can you make a counter example where this doesn't look good? > > > > Moreover, we have channels that are not tied to a particular device - > > > they are for a group of them. Example: setting timings for IDE controller. > > > Sure, we can just say "open /dev/hda instead of /dev/hda5", but then we > > > are back to the "find related file" problem you tried to avoid. > > > > It does not seems appropriate to permit to change IDE timings using an > > handle to a partition... nor it seems very safe under a permissions > > point of view. > > However, we _do_ allow that. Right now. And yes, I agree that we should > go to separate file for that. And we are right back to finding a related > file. I'd prefer to make what you often call a crapectomy: no IDE timing change using a partition handle. It's something like to permit that on a LVM handle, it's stupid... About tty and vcs split: there the problem is more subtle and it's related to a missing separation of keyboard and screen. After to have done this choice (i.e. to have the some behaviour of serial port) someone has realized that to read from console screen it's a sensible action (to fetch current content). This is the typical case where to have /dev/tty1/ioctl does not substitute to have another device for console screen reading. Note that it's a *different* device (different permission, etc.). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: > > On Sun, 20 May 2001, Abramo Bagnara wrote: > > > > It may have several. Which one? > > > > Can you explain better this? > > Example: console. You want to be able to pass font changes. I'm > less than sure that putting them on the same channel as, e.g., > keyboard mapping changes is a good idea. We can do it, but I don't > see why it's natural thing to do. Moreover, you already have > /dev/vcs and /dev/vcsa. Can you explain what's the difference > between them (per-VC channels) and keyboard mapping (also per-VC)? > > Face it, we _already_ have more than one side band. This does not imply it's necessarily a good idea. We are comparing echo "9600" > /proc/self/fd/0/speed (or /dev/ttyS0/speed) echo "8" > /proc/self/fd/0/bits (or /dev/ttyS0/bits) with echo -e "speed 9600\nbits 8" > /proc/self/fd/0/ioctl (or /dev/ttyS0/ioctl). My personal preference goes to the latter, but it's a matter of taste (and convention choice) (echo -n "keymap " ; cat keymap) > /dev/tty1/ioctl (echo -n "font " ; cat font) > /dev/tty1/ioctl This seems ugly to you? > Moreover, we have channels that are not tied to a particular device - > they are for a group of them. Example: setting timings for IDE controller. > Sure, we can just say "open /dev/hda instead of /dev/hda5", but then we > are back to the "find related file" problem you tried to avoid. It does not seems appropriate to permit to change IDE timings using an handle to a partition... nor it seems very safe under a permissions point of view. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: > > On 20 May 2001, Kai Henningsen wrote: > > > I've seen this question several times in this thread. I haven't seen the > > obvious answer, though. > > > > Have a new system call: > > > > ctlfd = open_device_control_fd(fd); > > If fd is something that doesn't have a control interface (say, it already > > is a control filehandle), this returns an appropriate error code. > > It may have several. Which one? Can you explain better this? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Alexander Viro wrote: > > On Sun, 20 May 2001, Abramo Bagnara wrote: > > > I've just had a "so simple to risk to be stupid" idea. > > > > To have /proc/self/fd/N/ioctl would not have the potential to suppress > > ioctl needs for *all* current uses? > > No, it wouldn't. For one thing, it messes the only half-decent part of > procfs. For another, the real issue is how to eliminate the bogus > ioctls from userland programs and what to replace them with. Linus wrote: > The problem with ioctl is that not only are people passing ioctl's > pointers to structures, but: > - they're not telling how big the structure is > - the structure can have pointers to other places > - sometimes it modifies the structure passed in > None of which are "network-nice". Basically, ioctl() is historically used > as a "pass any crap into driver , and the driver - and ONLY the driver > - will know what to do with it". > And when _only_ a driver knows what the arguments mean, upper layers can't > encapsulate them. Upper layers cannot make a packet of the argument and > send it over the network to another machine. Upper layers cannot do > sanity-checking on things like "is this argument a valid pointer". Which > means, for example, that not only can you not send the ioctl arguments > anywhere, but ioctl's have also historically been a hot-bed of bugs. Suppose now to have a convention that control stream are in the form: "ACTION ARGUMENTS" Then we have echo "speed 19200" > /proc/self/fd/0/ioctl instead of stty 19200 It seems to me something different from a pile of shit ;-) And it may works also via NFS (with some changes). > Crappy API won't become better if you simply change the calling conventions. > And problem with ioctls is that most of them are crappy APIs. Coming from > authors' laziness and/or debility. > > So there is no easy way to solve that stuff - we'll need to rethink tons > of badly designed interfaces. This is orthogonal wrt ioctl problems pointed by Linus. I've simply proposed an *infrastructure* for better interfaces. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Alexander Viro wrote: > > On Sat, 19 May 2001, Linus Torvalds wrote: > > > > > What you're really proposing is to make ioctl's be ASCII strings. > > > > Which is not necessarily a bad idea, and I think plan9 did something > > similar (or rather, if I remember correctly, plan9 has control streams > > that were ASCII. Or am I confused?). > > You are not. Control streams in question look like normal files. Normally > driver exports a tree with several data files (e.g. fd0, fd1, fd2, fd3) > and several control files (e.g. fd0ctl, fd1ctl, fd2ctl, fd3ctl). write() > to the latter passes commands. No extra syscalls needed. I've just had a "so simple to risk to be stupid" idea. To have /proc/self/fd/N/ioctl would not have the potential to suppress ioctl needs for *all* current uses? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Alexander Viro wrote: On Sat, 19 May 2001, Linus Torvalds wrote: What you're really proposing is to make ioctl's be ASCII strings. Which is not necessarily a bad idea, and I think plan9 did something similar (or rather, if I remember correctly, plan9 has control streams that were ASCII. Or am I confused?). You are not. Control streams in question look like normal files. Normally driver exports a tree with several data files (e.g. fd0, fd1, fd2, fd3) and several control files (e.g. fd0ctl, fd1ctl, fd2ctl, fd3ctl). write() to the latter passes commands. No extra syscalls needed. I've just had a so simple to risk to be stupid idea. To have /proc/self/fd/N/ioctl would not have the potential to suppress ioctl needs for *all* current uses? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Alexander Viro wrote: On Sun, 20 May 2001, Abramo Bagnara wrote: I've just had a so simple to risk to be stupid idea. To have /proc/self/fd/N/ioctl would not have the potential to suppress ioctl needs for *all* current uses? No, it wouldn't. For one thing, it messes the only half-decent part of procfs. For another, the real issue is how to eliminate the bogus ioctls from userland programs and what to replace them with. Linus wrote: The problem with ioctl is that not only are people passing ioctl's pointers to structures, but: - they're not telling how big the structure is - the structure can have pointers to other places - sometimes it modifies the structure passed in None of which are network-nice. Basically, ioctl() is historically used as a pass any crap into driver , and the driver - and ONLY the driver - will know what to do with it. And when _only_ a driver knows what the arguments mean, upper layers can't encapsulate them. Upper layers cannot make a packet of the argument and send it over the network to another machine. Upper layers cannot do sanity-checking on things like is this argument a valid pointer. Which means, for example, that not only can you not send the ioctl arguments anywhere, but ioctl's have also historically been a hot-bed of bugs. Suppose now to have a convention that control stream are in the form: ACTION ARGUMENTS Then we have echo speed 19200 /proc/self/fd/0/ioctl instead of stty 19200 It seems to me something different from a pile of shit ;-) And it may works also via NFS (with some changes). Crappy API won't become better if you simply change the calling conventions. And problem with ioctls is that most of them are crappy APIs. Coming from authors' laziness and/or debility. So there is no easy way to solve that stuff - we'll need to rethink tons of badly designed interfaces. This is orthogonal wrt ioctl problems pointed by Linus. I've simply proposed an *infrastructure* for better interfaces. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: On 20 May 2001, Kai Henningsen wrote: I've seen this question several times in this thread. I haven't seen the obvious answer, though. Have a new system call: ctlfd = open_device_control_fd(fd); If fd is something that doesn't have a control interface (say, it already is a control filehandle), this returns an appropriate error code. It may have several. Which one? Can you explain better this? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: On Sun, 20 May 2001, Abramo Bagnara wrote: It may have several. Which one? Can you explain better this? Example: console. You want to be able to pass font changes. I'm less than sure that putting them on the same channel as, e.g., keyboard mapping changes is a good idea. We can do it, but I don't see why it's natural thing to do. Moreover, you already have /dev/vcsn and /dev/vcsan. Can you explain what's the difference between them (per-VC channels) and keyboard mapping (also per-VC)? Face it, we _already_ have more than one side band. This does not imply it's necessarily a good idea. We are comparing echo 9600 /proc/self/fd/0/speed (or /dev/ttyS0/speed) echo 8 /proc/self/fd/0/bits (or /dev/ttyS0/bits) with echo -e speed 9600\nbits 8 /proc/self/fd/0/ioctl (or /dev/ttyS0/ioctl). My personal preference goes to the latter, but it's a matter of taste (and convention choice) (echo -n keymap ; cat keymap) /dev/tty1/ioctl (echo -n font ; cat font) /dev/tty1/ioctl This seems ugly to you? Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. It does not seems appropriate to permit to change IDE timings using an handle to a partition... nor it seems very safe under a permissions point of view. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: On Sun, 20 May 2001, Abramo Bagnara wrote: Face it, we _already_ have more than one side band. This does not imply it's necessarily a good idea. We are comparing echo 9600 /proc/self/fd/0/speed (or /dev/ttyS0/speed) echo 8 /proc/self/fd/0/bits (or /dev/ttyS0/bits) with echo -e speed 9600\nbits 8 /proc/self/fd/0/ioctl (or /dev/ttyS0/ioctl). How about reading from them? You are forcing restriction that may make sense in some cases, but doesn't look good for everything. exec 3/dev/ttyS0/ioctl exec 43 echo speed 3 cat 4 exec 3- exec 4- Can you make a counter example where this doesn't look good? Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. It does not seems appropriate to permit to change IDE timings using an handle to a partition... nor it seems very safe under a permissions point of view. However, we _do_ allow that. Right now. And yes, I agree that we should go to separate file for that. And we are right back to finding a related file. I'd prefer to make what you often call a crapectomy: no IDE timing change using a partition handle. It's something like to permit that on a LVM handle, it's stupid... About tty and vcs split: there the problem is more subtle and it's related to a missing separation of keyboard and screen. After to have done this choice (i.e. to have the some behaviour of serial port) someone has realized that to read from console screen it's a sensible action (to fetch current content). This is the typical case where to have /dev/tty1/ioctl does not substitute to have another device for console screen reading. Note that it's a *different* device (different permission, etc.). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Linus Torvalds wrote:
>
> [ Attribution is gone, so I just deleted it.. ]
>
> > > > > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > > >
> > > > Hmm, there might be problem with this. How do you change speed without
> > > > reopening device? [Remember: your mice knows when you close device]
>
> The naming scheme is not a replacement for these kinds of ioctl's - it's
> just a way to make them less critical, and get people thinking in other
> directions so that we don't get _more_ ioctl's.
However
fchdir(fd);
s = open("speed");
write(s, "19200\n", 6);
would be enough to solve the problem Pavel is pointing also without the
need to use ioctl.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Alexander Viro wrote: > > Folks, before you get all excited about cramming side effects into > open(2), consider the following case: > > 1) opening "/dev/zero/start_nuclear_war" has a certain side effect. > > 2) Local user does the following: > ln -sf /dev/zero/start_nuclear_war bar > while true; do > mkdir foo > rmdir foo > ln -sf bar foo > rm foo > done > > 3) Comes the night and root runs (from crontab) updatedb(8). Said beast > includes find(1). With sufficiently bad timing find _will_ be tricked > into attempt to open foo. It will honestly lstat() it, all right. But > there's no way to make sure that subsequent open() on the found directory > will get the same object. > > 4) Side effect happens... > > Similar scenarios can be found for other programs run by/as root, but I > think that the point is obvious - side effects on open() are not a good > idea. Yes, we can play with checking for O_DIRECTORY, yodda, yodda, but > I wouldn't bet a dime on security of a system with such side effects. > A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a > no-op. Breaking that assumption is a Bad Thing(tm). Can't this easily avoided if the needed action is not < /dev/zero/start_nuclear_war or > /dev/zero/start_nuclear_war but echo "I'm evil" > /dev/zero/start_nuclear_war ? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Linus Torvalds wrote: [ Attribution is gone, so I just deleted it.. ] fd = open(/dev/tty00/nonblock,9600,n8, O_RDWR); Hmm, there might be problem with this. How do you change speed without reopening device? [Remember: your mice knows when you close device] The naming scheme is not a replacement for these kinds of ioctl's - it's just a way to make them less critical, and get people thinking in other directions so that we don't get _more_ ioctl's. However fchdir(fd); s = open(speed); write(s, 19200\n, 6); would be enough to solve the problem Pavel is pointing also without the need to use ioctl. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Alexander Viro wrote: Folks, before you get all excited about cramming side effects into open(2), consider the following case: 1) opening /dev/zero/start_nuclear_war has a certain side effect. 2) Local user does the following: ln -sf /dev/zero/start_nuclear_war bar while true; do mkdir foo rmdir foo ln -sf bar foo rm foo done 3) Comes the night and root runs (from crontab) updatedb(8). Said beast includes find(1). With sufficiently bad timing find _will_ be tricked into attempt to open foo. It will honestly lstat() it, all right. But there's no way to make sure that subsequent open() on the found directory will get the same object. 4) Side effect happens... Similar scenarios can be found for other programs run by/as root, but I think that the point is obvious - side effects on open() are not a good idea. Yes, we can play with checking for O_DIRECTORY, yodda, yodda, but I wouldn't bet a dime on security of a system with such side effects. A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a no-op. Breaking that assumption is a Bad Thing(tm). Can't this easily avoided if the needed action is not /dev/zero/start_nuclear_war or /dev/zero/start_nuclear_war but echo I'm evil /dev/zero/start_nuclear_war ? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
Jes Sorensen wrote: > > >>>>> "Abramo" == Abramo Bagnara <[EMAIL PROTECTED]> writes: > > Abramo> "David S. Miller" wrote: > >> One final point, I want to reiterate that I believe: > >> > >> foo = readl(>bar); > >> > >> is perfectly legal and should not be discouraged and in particular, > >> not made painful to do. > > Abramo> I disagree: regs it's not a dereferenceable thing and I think > Abramo> it's an abuse of pointer type. You're keeping a pointer that > Abramo> need a big sign on it saying "Don't dereference me", it's a > Abramo> mess. > > Thats complete rubbish, in many cases the regs structure matches a > regs structure seen by another CPU on the other side of the PCI bus > (ie. the firmware case). There is nothing wrong with the above > approach as long as you keep in mind that you cannot dereference the > struct without using readl and you have to make sure to explicitly do > padding in the struct (not all CPUs guarantee the same natural > alignment). "As long as you handle with gloves thick enough such a shit, there's no problems.." -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
Jes Sorensen wrote: Abramo == Abramo Bagnara [EMAIL PROTECTED] writes: Abramo David S. Miller wrote: One final point, I want to reiterate that I believe: foo = readl(regs-bar); is perfectly legal and should not be discouraged and in particular, not made painful to do. Abramo I disagree: regs it's not a dereferenceable thing and I think Abramo it's an abuse of pointer type. You're keeping a pointer that Abramo need a big sign on it saying Don't dereference me, it's a Abramo mess. Thats complete rubbish, in many cases the regs structure matches a regs structure seen by another CPU on the other side of the PCI bus (ie. the firmware case). There is nothing wrong with the above approach as long as you keep in mind that you cannot dereference the struct without using readl and you have to make sure to explicitly do padding in the struct (not all CPUs guarantee the same natural alignment). As long as you handle with gloves thick enough such a shit, there's no problems.. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
"David S. Miller" wrote: > > Abramo Bagnara writes: > > it's perfectly fine to have: > > > > regs = (struct reg *) ioremap(addr, size); > > foo = readl((unsigned long)>bar); > > > > I don't see how one can find this valid compared to my preference of > just plain readl(>bar); You're telling me it's nicer to have the > butt ugly cast there which serves no purpose? It's right API a bit misused (to allow your request to use fields by name) i.e. foo = readl((unsigned long)>bar); vs a wrong API that need a cast to be used correctly i.e. rme9652->iobase = (unsigned long) ioremap(rme9652->port, RME9652_IO_EXTENT); Taken in account that the main point is to not have fake pointers here and there, my choice would be obvious. > One could argue btw that structure offsets are less error prone to > code than register offset defines out the wazoo. offset defines are never correct on some architecture while being incorrect on some other, that's the whole point: a wrong #define is likely squashed during the very first phase of driver development. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
"David S. Miller" wrote: > > Abramo Bagnara writes: > > IMO this is a far less effective debugging strategy. > > I agree with you. > > But guess what driver authors are going to do? They are going to cast > the thing left and right. And sure you can then search for that, but > it isn't likely to make people fix this from the start. We can easily find now the current misuses (I've already posted a complete list some time ago) and ensure that authors will do the right thing. True benefits will come in future from to have a correct API (the only point to remember is that ioremap returned value and readl arguments is *not* a pointer, this is not questionable). > > I suppose the point is that there is a fine line wrt. using APIs to > influence people to "do the right thing", and this has been > exemplified in several threads I've been involved in wrt. PCI dma > and other topics. :-) > > One final point, I want to reiterate that I believe: > > foo = readl(>bar); > > is perfectly legal and should not be discouraged and in particular, > not made painful to do. I disagree: regs it's not a dereferenceable thing and I think it's an abuse of pointer type. You're keeping a pointer that need a big sign on it saying "Don't dereference me", it's a mess. However you might like to substitute this with: #define fld_readl(cookie, str, fld) readl(cookie + (unsigned long)&((struct str *) 0)->fld) or without that, it's perfectly fine to have: regs = (struct reg *) ioremap(addr, size); foo = readl((unsigned long)>bar); It's a driver author matter of preference, that don't touch the fact that API is correct. However I've verified that often this lead to unexpected errors due to different alignment on different architecture and this is why I personally prefer constant offsets over structures fields. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
David S. Miller wrote: Abramo Bagnara writes: IMO this is a far less effective debugging strategy. I agree with you. But guess what driver authors are going to do? They are going to cast the thing left and right. And sure you can then search for that, but it isn't likely to make people fix this from the start. We can easily find now the current misuses (I've already posted a complete list some time ago) and ensure that authors will do the right thing. True benefits will come in future from to have a correct API (the only point to remember is that ioremap returned value and readl arguments is *not* a pointer, this is not questionable). I suppose the point is that there is a fine line wrt. using APIs to influence people to do the right thing, and this has been exemplified in several threads I've been involved in wrt. PCI dma and other topics. :-) One final point, I want to reiterate that I believe: foo = readl(regs-bar); is perfectly legal and should not be discouraged and in particular, not made painful to do. I disagree: regs it's not a dereferenceable thing and I think it's an abuse of pointer type. You're keeping a pointer that need a big sign on it saying Don't dereference me, it's a mess. However you might like to substitute this with: #define fld_readl(cookie, str, fld) readl(cookie + (unsigned long)((struct str *) 0)-fld) or without that, it's perfectly fine to have: regs = (struct reg *) ioremap(addr, size); foo = readl((unsigned long)regs-bar); It's a driver author matter of preference, that don't touch the fact that API is correct. However I've verified that often this lead to unexpected errors due to different alignment on different architecture and this is why I personally prefer constant offsets over structures fields. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
David S. Miller wrote: Abramo Bagnara writes: it's perfectly fine to have: regs = (struct reg *) ioremap(addr, size); foo = readl((unsigned long)regs-bar); I don't see how one can find this valid compared to my preference of just plain readl(regs-bar); You're telling me it's nicer to have the butt ugly cast there which serves no purpose? It's right API a bit misused (to allow your request to use fields by name) i.e. foo = readl((unsigned long)regs-bar); vs a wrong API that need a cast to be used correctly i.e. rme9652-iobase = (unsigned long) ioremap(rme9652-port, RME9652_IO_EXTENT); Taken in account that the main point is to not have fake pointers here and there, my choice would be obvious. One could argue btw that structure offsets are less error prone to code than register offset defines out the wazoo. offset defines are never correct on some architecture while being incorrect on some other, that's the whole point: a wrong #define is likely squashed during the very first phase of driver development. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > The problem I see is that with the former solution nothing prevents
> > from to do:
>
> > regs->reg2 = 13;
>
> > That's indeed the reason to change ioremap prototype for 2.5.
>
> An alternative is to add an fixed offset to the cookie before returning it,
> and subtract it again in {read,write}[bwl].
You understand that in this way you change a compile time warning in a
runtime error (conditioned to path reaching, not easy to interpret,
etc.)
IMO this is a far less effective debugging strategy.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
"David S. Miller" wrote:
>
> Geert Uytterhoeven writes:
> > Since you're not allowed to use direct memory dereferencing on ioremapped
> > areas, wouldn't it be more logical to let ioremap() return an unsigned long
> > instead of a void *?
> >
> > Of course we then have to change readb() and friends to take a long as well,
> > but at least we'd get compiler warnings when someone tries to do a direct
> > dereference.
>
> There is a school of thought which believes that:
>
> struct xdev_regs {
> u32 reg1;
> u32 reg2;
> };
>
> val = readl(>reg2);
>
> is cleaner than:
>
> #define REG1 0x00
> #define REG2 0x04
>
> val = readl(regs + REG2);
>
> I'm personally ambivalent and believe that both cases should be allowed.
The problem I see is that with the former solution nothing prevents from
to do:
regs->reg2 = 13;
That's indeed the reason to change ioremap prototype for 2.5.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
David Woodhouse wrote:
[EMAIL PROTECTED] said:
The problem I see is that with the former solution nothing prevents
from to do:
regs-reg2 = 13;
That's indeed the reason to change ioremap prototype for 2.5.
An alternative is to add an fixed offset to the cookie before returning it,
and subtract it again in {read,write}[bwl].
You understand that in this way you change a compile time warning in a
runtime error (conditioned to path reaching, not easy to interpret,
etc.)
IMO this is a far less effective debugging strategy.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: unsigned long ioremap()?
David S. Miller wrote:
Geert Uytterhoeven writes:
Since you're not allowed to use direct memory dereferencing on ioremapped
areas, wouldn't it be more logical to let ioremap() return an unsigned long
instead of a void *?
Of course we then have to change readb() and friends to take a long as well,
but at least we'd get compiler warnings when someone tries to do a direct
dereference.
There is a school of thought which believes that:
struct xdev_regs {
u32 reg1;
u32 reg2;
};
val = readl(regs-reg2);
is cleaner than:
#define REG1 0x00
#define REG2 0x04
val = readl(regs + REG2);
I'm personally ambivalent and believe that both cases should be allowed.
The problem I see is that with the former solution nothing prevents from
to do:
regs-reg2 = 13;
That's indeed the reason to change ioremap prototype for 2.5.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Linus Torvalds wrote: > > On Thu, 19 Apr 2001, Abramo Bagnara wrote: > > > > > [ Using file descriptors ] > > > > This would also permit: > > - to have poll() > > - to use mmap() to obtain the userspace area > > > > It would become something very near to sacred Unix dogmas ;-) > > No, this is NOT what the UNIX dogmas are all about. > > When UNIX says "everything is a file", it really means that "everything is > a stream of bytes". Things like magic operations on file desciptors are > _anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic > semantics of file descriptors is NOT Unix dogma at all, it is a horrible > corruption of the original UNIX cleanlyness. Nice outpouring indeed, it seems taken from L'Ouvre au Noir by Marguerite Yourcenar ;-))) You're perfectly right but the file descriptor solution appeared to me a nice way to work around the Unix limitation to have poll(2) working only on file descriptor. Said this, I've no doubt that a better poll-like syscall would solve all that in a more elegant way. You understand that sometime we've no other choice that to design workarounds to minimize needed changes (and then often to maximize acceptance probability). OTOH you may always decide to do things in the elegant way, you've such a responsibility for linux kernel. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Alexander Viro wrote:
>
> I suspect that simple pipe with would be sufficient to handle contention
> case - nothing fancy needed (read when you need to block, write upon up()
> when you have contenders)
>
> Would something along the lines of (inline as needed, etc.)
>
> down:
> lock decl count
> js __down_failed
> down_done:
> ret
>
> up:
> lock incl count
> jle __up_waking
> up_done:
> ret
>
> __down_failed:
> call down_failed
> jmp down_done
> __up_waking:
> call up_waking
> jmp up_done
>
> down_failed()
> {
> read(pipe_fd, , 1);
> }
>
> up_waking()
> {
> write(pipe_fd, , 1);
> }
>
> be enough?
There is something wonderful in this simple solution.
However I've a few doubts:
- choice policy for thread to wake is not selectable
- we separate shared memory area from file descriptor
- the implementation of down_try has neither been discussed nor
excluded, but I don't see how to implement it
The implementation of a specific filesystem seems to me more flexyble.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Alon Ziv wrote: > > Hmm... > I already started (long ago, and abandoned since due to lack of time :-( ) > down another path; I'd like to resurrect it... > > My lightweight-semaphores were actually even simpler in userspace: > * the userspace struct was just a signed count and a file handle. > * Uncontended case is exactly like Linus' version (i.e., down() is decl + > js, up() is incl()). > * The contention syscall was (in my implementation) an ioctl on the FH; the > FH was a special one, from a private syscall (although with the new VFS I'd > have written it as just another specialized FS, or even referred into the > SysVsem FS). > > So, there is no chance for user corruption of kernel data (as it just ain't > there...); and the contended-case cost is probably equivalent (VFS cost vs. > validation). This would also permit: - to have poll() - to use mmap() to obtain the userspace area It would become something very near to sacred Unix dogmas ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Alon Ziv wrote: Hmm... I already started (long ago, and abandoned since due to lack of time :-( ) down another path; I'd like to resurrect it... My lightweight-semaphores were actually even simpler in userspace: * the userspace struct was just a signed count and a file handle. * Uncontended case is exactly like Linus' version (i.e., down() is decl + js, up() is incl()). * The contention syscall was (in my implementation) an ioctl on the FH; the FH was a special one, from a private syscall (although with the new VFS I'd have written it as just another specialized FS, or even referred into the SysVsem FS). So, there is no chance for user corruption of kernel data (as it just ain't there...); and the contended-case cost is probably equivalent (VFS cost vs. validation). This would also permit: - to have poll() - to use mmap() to obtain the userspace area It would become something very near to sacred Unix dogmas ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Alexander Viro wrote:
I suspect that simple pipe with would be sufficient to handle contention
case - nothing fancy needed (read when you need to block, write upon up()
when you have contenders)
Would something along the lines of (inline as needed, etc.)
down:
lock decl count
js __down_failed
down_done:
ret
up:
lock incl count
jle __up_waking
up_done:
ret
__down_failed:
call down_failed
jmp down_done
__up_waking:
call up_waking
jmp up_done
down_failed()
{
read(pipe_fd, dummy, 1);
}
up_waking()
{
write(pipe_fd, dummy, 1);
}
be enough?
There is something wonderful in this simple solution.
However I've a few doubts:
- choice policy for thread to wake is not selectable
- we separate shared memory area from file descriptor
- the implementation of down_try has neither been discussed nor
excluded, but I don't see how to implement it
The implementation of a specific filesystem seems to me more flexyble.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Linus Torvalds wrote: On Thu, 19 Apr 2001, Abramo Bagnara wrote: [ Using file descriptors ] This would also permit: - to have poll() - to use mmap() to obtain the userspace area It would become something very near to sacred Unix dogmas ;-) No, this is NOT what the UNIX dogmas are all about. When UNIX says "everything is a file", it really means that "everything is a stream of bytes". Things like magic operations on file desciptors are _anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic semantics of file descriptors is NOT Unix dogma at all, it is a horrible corruption of the original UNIX cleanlyness. Nice outpouring indeed, it seems taken from L'Ouvre au Noir by Marguerite Yourcenar ;-))) You're perfectly right but the file descriptor solution appeared to me a nice way to work around the Unix limitation to have poll(2) working only on file descriptor. Said this, I've no doubt that a better poll-like syscall would solve all that in a more elegant way. You understand that sometime we've no other choice that to design workarounds to minimize needed changes (and then often to maximize acceptance probability). OTOH you may always decide to do things in the elegant way, you've such a responsibility for linux kernel. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 cleanups
Jeff Garzik wrote: > > Pavel Machek wrote: > > > > Hi! > > > > These are tiny cleanups you might like. sizes are "logically" > > long. No, it does not matter on i386. > > > > processor.h makes INIT_TSS look much more readable. [Please tell me > > applied or rejected] > > > > Pavel > > > > Index: include/asm-i386/posix_types.h > > === > > RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v > > retrieving revision 1.1.1.1 > > diff -u -u -r1.1.1.1 posix_types.h > > --- include/asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 > > +++ include/asm-i386/posix_types.h 2001/02/13 13:49:18 > > @@ -16,9 +16,9 @@ > > typedef unsigned short __kernel_ipc_pid_t; > > typedef unsigned short __kernel_uid_t; > > typedef unsigned short __kernel_gid_t; > > -typedef unsigned int __kernel_size_t; > > -typedef int__kernel_ssize_t; > > -typedef int__kernel_ptrdiff_t; > > +typedef unsigned long __kernel_size_t; > > +typedef long __kernel_ssize_t; > > +typedef long __kernel_ptrdiff_t; > > If it doesn't matter on i386 why bother? It helps with printf %-formats to avoid some arch specific warnings. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 cleanups
Jeff Garzik wrote: Pavel Machek wrote: Hi! These are tiny cleanups you might like. sizes are "logically" long. No, it does not matter on i386. processor.h makes INIT_TSS look much more readable. [Please tell me applied or rejected] Pavel Index: include/asm-i386/posix_types.h === RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 posix_types.h --- include/asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 +++ include/asm-i386/posix_types.h 2001/02/13 13:49:18 @@ -16,9 +16,9 @@ typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; -typedef unsigned int __kernel_size_t; -typedef int__kernel_ssize_t; -typedef int__kernel_ptrdiff_t; +typedef unsigned long __kernel_size_t; +typedef long __kernel_ssize_t; +typedef long __kernel_ptrdiff_t; If it doesn't matter on i386 why bother? It helps with printf %-formats to avoid some arch specific warnings. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Large scale kernel performance recording
Keith Owens wrote:
>
> Sigh. Why do you always spot the typos *after* pressing send?
>
> On Thu, 29 Mar 2001 00:07:02 +1000,
> Keith Owens <[EMAIL PROTECTED]> wrote:
> > copy_desired_counter_values()
> > {
> >volatile int *p_flag = /* address of flag for desired cpu */;
> >volatile __s64 *p_counter = /* address of counter for desired cpu and instance
>*/;
> >__s64 counter; /* local copy */
> >
> >do {
> > counter = *p_counter;
> >} while (!*p_flag && counter == *p_counter);
> > }
>
> Should be while (*p_flag || counter != *p_counter);
And here you've the race:
kernel: user:
++flag;
wmb();
counter += delta; (first 32 bits)
counter = *p_counter;
counter += delta; (last 32 bits)
wmb();
--flag;
wmb();
... *p_flag test
++flag;
counter += delta; (first 32 bits)
counter == *p_counter test
counter += delta; (last 32 bits)
wmb();
--flag;
wmb();
Improbable but theoretically possible.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Large scale kernel performance recording
Keith Owens wrote:
>
> All counters are 64 bit, 4 Gb is not enough for everybody. This raises
> its own problem, some architectures do not have atomic reads, writes or
> increments for 64 bit fields but must treat them as 2 32 bit words.
> This race exists.
>
> user space:kernel
> read word 0
> read word 0
> read word 1
> update
> store word 0
> store word 1
> read word 1
>
> That gets really interesting when the counter is about to overflow from
> 2**32-1 to 2**32. User space will read two words of zero.
>
> To close this race without a kernel call to get a semaphore (avoiding
> context switches), there is an int at the start of each cpu's data,
> this field counts the number of data updates in progress. User space
> can see the int as part of the mmapped data, like this.
>
> Global header page.
> int flag )
> performance counter 1) data for cpu 0, page aligned
> performance counter 2... )
> int flag )
> performance counter 1) data for cpu 1, page aligned
> performance counter 2... )
>
> The application calculates the address of the flag for the cpu it is
> interested in and the address of the counter for the instance it wants
> to read. Then
>
> user space:
>
> copy_desired_counter_values()
> {
> volatile int *p_flag = /* address of flag for desired cpu */;
> volatile __s64 *p_counter = /* address of counter for desired cpu and instance
>*/;
> __s64 counter; /* local copy */
>
> do {
> counter = *p_counter;
> } while (!*p_flag && counter == *p_counter);
I suppose you've made a mistake writing the continue condition.
> }
>
> kernel:
>
> ++perf_flag_for_current_cpu;
> smp_wmb();
> counter += delta;
> smp_wmb();
> --perf_flag_for_current_cpu;
> smp_wmb();
>
> Looping until counter == *p_counter ensures that user space always sees
> a stable value, even if the kernel is updating the counter at the same
> time. A non-zero flag tells user space that an update is in progress
> so the data it got, while stable, might be invalid.
>
> The flag check is required because user space on one cpu can read data
> from another cpu while the second cpu is updating the counter. The
> flag is per cpu and is only updated by the kernel on that cpu so an int
> is both smp and interrupt safe, it does not need to be atomic.
> smp_wmb() is used after each update to guarantee strong write ordering.
I've faced this problem in the past months for ALSA and I think to be
able to propose you a better solution.
I see two problems in your solution:
1) the continue condition is wrong and I'm not sure you'll be able to
indicate one without races with your current fields
2) you've no way to have multiple related counter that need to be read
congruently (i.e. atomically).
3) your solution may be wrong if field values sequences is not
monothonic
I draw my solution:
struct perfcounter {
int begin, end; /* both initialized to 0 */
u64 counter1;
u64 counter2;
};
kernel:
s->begin++;
wmb();
update performance counter(s)
wmb();
s->end++;
user:
volatile struct perfcounter *s;
do {
_end = s->end;
c1 = s->counter1;
c2 = s->counter2;
} while (_end != s->begin);
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Large scale kernel performance recording
Keith Owens wrote:
All counters are 64 bit, 4 Gb is not enough for everybody. This raises
its own problem, some architectures do not have atomic reads, writes or
increments for 64 bit fields but must treat them as 2 32 bit words.
This race exists.
user space:kernel
read word 0
read word 0
read word 1
update
store word 0
store word 1
read word 1
That gets really interesting when the counter is about to overflow from
2**32-1 to 2**32. User space will read two words of zero.
To close this race without a kernel call to get a semaphore (avoiding
context switches), there is an int at the start of each cpu's data,
this field counts the number of data updates in progress. User space
can see the int as part of the mmapped data, like this.
Global header page.
int flag )
performance counter 1) data for cpu 0, page aligned
performance counter 2... )
int flag )
performance counter 1) data for cpu 1, page aligned
performance counter 2... )
The application calculates the address of the flag for the cpu it is
interested in and the address of the counter for the instance it wants
to read. Then
user space:
copy_desired_counter_values()
{
volatile int *p_flag = /* address of flag for desired cpu */;
volatile __s64 *p_counter = /* address of counter for desired cpu and instance
*/;
__s64 counter; /* local copy */
do {
counter = *p_counter;
} while (!*p_flag counter == *p_counter);
I suppose you've made a mistake writing the continue condition.
}
kernel:
++perf_flag_for_current_cpu;
smp_wmb();
counter += delta;
smp_wmb();
--perf_flag_for_current_cpu;
smp_wmb();
Looping until counter == *p_counter ensures that user space always sees
a stable value, even if the kernel is updating the counter at the same
time. A non-zero flag tells user space that an update is in progress
so the data it got, while stable, might be invalid.
The flag check is required because user space on one cpu can read data
from another cpu while the second cpu is updating the counter. The
flag is per cpu and is only updated by the kernel on that cpu so an int
is both smp and interrupt safe, it does not need to be atomic.
smp_wmb() is used after each update to guarantee strong write ordering.
I've faced this problem in the past months for ALSA and I think to be
able to propose you a better solution.
I see two problems in your solution:
1) the continue condition is wrong and I'm not sure you'll be able to
indicate one without races with your current fields
2) you've no way to have multiple related counter that need to be read
congruently (i.e. atomically).
3) your solution may be wrong if field values sequences is not
monothonic
I draw my solution:
struct perfcounter {
int begin, end; /* both initialized to 0 */
u64 counter1;
u64 counter2;
};
kernel:
s-begin++;
wmb();
update performance counter(s)
wmb();
s-end++;
user:
volatile struct perfcounter *s;
do {
_end = s-end;
c1 = s-counter1;
c2 = s-counter2;
} while (_end != s-begin);
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Large scale kernel performance recording
Keith Owens wrote:
Sigh. Why do you always spot the typos *after* pressing send?
On Thu, 29 Mar 2001 00:07:02 +1000,
Keith Owens [EMAIL PROTECTED] wrote:
copy_desired_counter_values()
{
volatile int *p_flag = /* address of flag for desired cpu */;
volatile __s64 *p_counter = /* address of counter for desired cpu and instance
*/;
__s64 counter; /* local copy */
do {
counter = *p_counter;
} while (!*p_flag counter == *p_counter);
}
Should be while (*p_flag || counter != *p_counter);
And here you've the race:
kernel: user:
++flag;
wmb();
counter += delta; (first 32 bits)
counter = *p_counter;
counter += delta; (last 32 bits)
wmb();
--flag;
wmb();
... *p_flag test
++flag;
counter += delta; (first 32 bits)
counter == *p_counter test
counter += delta; (last 32 bits)
wmb();
--flag;
wmb();
Improbable but theoretically possible.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro wrote:
>
>
> > But you're forgetting that we need to cope with non collaborative
> > applications (that *use* ioctl).
>
> Erm. If ioctls are device-specific - the program is already bound to
> specific driver. If they are for class of devices (and if I guessed
> right that's the case you are interested in - sound, isn't it?) we
> could let the stub driver in kernel open two pipes and redirect
> read()/write() on device to the first one turn ioctls into read()/write()
> on the second. That way you can get userland programs serving that
> stuff with no magic required.
>
> I mean something along the lines of
>
> foo_write(struct file *file, char *buf, size_t size, loff_t *ppos)
> {
> return f1->f_ops->write(file, buf, size, ppos);
> }
> foo_ioctl(struct file *file, int cmd, long arg)
> {
> loff_t dummy;
> switch (cmd) {
> case SNDCTL_DSP_RESET:
> f2->f_ops->write(file, "dsp_reset", 10, );
> return 0;
>
> }
> }
> where f1 and f2 are named pipes opened at init time. Notice that
> it doesn't introduce extra copying - just splits the stream with OOB data
> into two normal byte streams that can be served by naive userland code.
> After that any client that uses current sound API is able to talk to
> userland drivers and said drivers don't have to pull any special tricks -
> they just open two pipes and do usual select()/read()/write() loop.
> Kernel side is also quite simple that way - plain redirect for read/write
> and trivial decoder for the sound ioctls.
I agree, and this is how I wanted to implement it (apart that I thought
to packetize read/write/ioctl with an header and then to avoid to have
two pipes).
This has two major drawbacks (that have discouraged me):
a) no mmap support
b) the kernel side need to know the details of ioctl contents
a) bring to have an incomplete solution
b) bring the kernel space to be OSS dependent then giving a not general
solution for user space drivers.
The only thing I see that would cope with these drawbacks is to allow a
privileged server application to mmap the address space of another
client application. Then:
a) is solved trivially
b) is ok because server would read/write directly ioctl arguments from
client address space.
Security is a non issue here as also for kernel space driver
applications expose all their address space to driver.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro wrote: > > On Wed, 7 Mar 2001, Abramo Bagnara wrote: > > > Alexander Viro wrote: > > > > > > On Wed, 7 Mar 2001, Jeremy Elson wrote: > > > > > > > Right now, my code looks something like this: (it might make more > > > > sense if you know that I've written a framework for writing user-space > > > > device drivers... I'm going to be releasing it soon, hopefully after I > > > > resolve this performance problem. Or maybe before, if it's hard.) > > > > > > Ugh. Why not make that a named pipe and use zerocopy stuff for pipes? > > > I.e. why bother with making it look like a character device rather than > > > a FIFO? > > > > What about ioctl? Device drivers sometimes need it ;-) > > No, they don't. OOB data is equivalent to data on parallel channel. Al, you're perfectly right in principle (although last time I've checked pipe and unix socket did not support OOB data. Is this changed recently?). But you're forgetting that we need to cope with non collaborative applications (that *use* ioctl). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro wrote: > > On Wed, 7 Mar 2001, Jeremy Elson wrote: > > > Right now, my code looks something like this: (it might make more > > sense if you know that I've written a framework for writing user-space > > device drivers... I'm going to be releasing it soon, hopefully after I > > resolve this performance problem. Or maybe before, if it's hard.) > > Ugh. Why not make that a named pipe and use zerocopy stuff for pipes? > I.e. why bother with making it look like a character device rather than > a FIFO? What about ioctl? Device drivers sometimes need it ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Jeremy Elson wrote:
>
> Marcelo Tosatti writes:
> >On Wed, 7 Mar 2001, Alexander Viro wrote:
> >> You are reinventing the wheel.
> >> man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
> >
> >With ptrace data will be copied twice. As far as I understood, Jeremy
> >wants to avoid that.
>
> Yes - I've been looking at the sys_ptrace code and it seems that it
> does two copies through the kernel (but, using access_process_vm
> instead of copy_from_user -- I'm not sure how they differ). I'm
> trying to reduce the number of copies by giving one process a pointer
> into another process's address space.
I've investigated this in past to do the same thing you're trying (in my
case I was interested in a full user space implementation of OSS
emulation layer for ALSA).
The other huge drawback for ptrace is the impossibility to use mmap.
With older versions of Linux it was feasible to mmap /proc/PID/mem and
this was a very elegant way to do the job.
Unfortunately this feature has been dropped, but I don't know for which
reasons.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Jeremy Elson wrote:
Marcelo Tosatti writes:
On Wed, 7 Mar 2001, Alexander Viro wrote:
You are reinventing the wheel.
man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
With ptrace data will be copied twice. As far as I understood, Jeremy
wants to avoid that.
Yes - I've been looking at the sys_ptrace code and it seems that it
does two copies through the kernel (but, using access_process_vm
instead of copy_from_user -- I'm not sure how they differ). I'm
trying to reduce the number of copies by giving one process a pointer
into another process's address space.
I've investigated this in past to do the same thing you're trying (in my
case I was interested in a full user space implementation of OSS
emulation layer for ALSA).
The other huge drawback for ptrace is the impossibility to use mmap.
With older versions of Linux it was feasible to mmap /proc/PID/mem and
this was a very elegant way to do the job.
Unfortunately this feature has been dropped, but I don't know for which
reasons.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro wrote: On Wed, 7 Mar 2001, Jeremy Elson wrote: Right now, my code looks something like this: (it might make more sense if you know that I've written a framework for writing user-space device drivers... I'm going to be releasing it soon, hopefully after I resolve this performance problem. Or maybe before, if it's hard.) Ugh. Why not make that a named pipe and use zerocopy stuff for pipes? I.e. why bother with making it look like a character device rather than a FIFO? What about ioctl? Device drivers sometimes need it ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro wrote: On Wed, 7 Mar 2001, Abramo Bagnara wrote: Alexander Viro wrote: On Wed, 7 Mar 2001, Jeremy Elson wrote: Right now, my code looks something like this: (it might make more sense if you know that I've written a framework for writing user-space device drivers... I'm going to be releasing it soon, hopefully after I resolve this performance problem. Or maybe before, if it's hard.) Ugh. Why not make that a named pipe and use zerocopy stuff for pipes? I.e. why bother with making it look like a character device rather than a FIFO? What about ioctl? Device drivers sometimes need it ;-) No, they don't. OOB data is equivalent to data on parallel channel. Al, you're perfectly right in principle (although last time I've checked pipe and unix socket did not support OOB data. Is this changed recently?). But you're forgetting that we need to cope with non collaborative applications (that *use* ioctl). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro wrote:
But you're forgetting that we need to cope with non collaborative
applications (that *use* ioctl).
Erm. If ioctls are device-specific - the program is already bound to
specific driver. If they are for class of devices (and if I guessed
right that's the case you are interested in - sound, isn't it?) we
could let the stub driver in kernel open two pipes and redirect
read()/write() on device to the first one turn ioctls into read()/write()
on the second. That way you can get userland programs serving that
stuff with no magic required.
I mean something along the lines of
foo_write(struct file *file, char *buf, size_t size, loff_t *ppos)
{
return f1-f_ops-write(file, buf, size, ppos);
}
foo_ioctl(struct file *file, int cmd, long arg)
{
loff_t dummy;
switch (cmd) {
case SNDCTL_DSP_RESET:
f2-f_ops-write(file, "dsp_reset", 10, dummy);
return 0;
}
}
where f1 and f2 are named pipes opened at init time. Notice that
it doesn't introduce extra copying - just splits the stream with OOB data
into two normal byte streams that can be served by naive userland code.
After that any client that uses current sound API is able to talk to
userland drivers and said drivers don't have to pull any special tricks -
they just open two pipes and do usual select()/read()/write() loop.
Kernel side is also quite simple that way - plain redirect for read/write
and trivial decoder for the sound ioctls.
I agree, and this is how I wanted to implement it (apart that I thought
to packetize read/write/ioctl with an header and then to avoid to have
two pipes).
This has two major drawbacks (that have discouraged me):
a) no mmap support
b) the kernel side need to know the details of ioctl contents
a) bring to have an incomplete solution
b) bring the kernel space to be OSS dependent then giving a not general
solution for user space drivers.
The only thing I see that would cope with these drawbacks is to allow a
privileged server application to mmap the address space of another
client application. Then:
a) is solved trivially
b) is ok because server would read/write directly ioctl arguments from
client address space.
Security is a non issue here as also for kernel space driver
applications expose all their address space to driver.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Major Clock Drift
Andrew Morton wrote: > > Alan Cox wrote: > > > > > > queued_writes=1; > > > > return; > > > > } > > > > } > > > > > > Unfortunately, that means that if machine crashes in interrupt, it may > > > "loose" printk message. That is considered bad (tm). > > > > The alternative is that the machine clock slides continually and the machine > > is unusable. This is considered even worse by most people > > Neither. I was going to dust off my enhanced "bust_spinlocks" > patch which sets a little flag when we're doing an > oops, BUG(), panic() or die(). If the flag > is set, printk() just punches through the lock. IMO to treat this as an exception it's not the right solution. A better alternative is to flush one entry of Alan proposed queue on the following conditions: - in_interrupt() is true AND queue is full -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Major Clock Drift
Andrew Morton wrote: Alan Cox wrote: queued_writes=1; return; } } Unfortunately, that means that if machine crashes in interrupt, it may "loose" printk message. That is considered bad (tm). The alternative is that the machine clock slides continually and the machine is unusable. This is considered even worse by most people Neither. I was going to dust off my enhanced "bust_spinlocks" patch which sets a little flag when we're doing an oops, BUG(), panic() or die(). If the flag is set, printk() just punches through the lock. IMO to treat this as an exception it's not the right solution. A better alternative is to flush one entry of Alan proposed queue on the following conditions: - in_interrupt() is true AND queue is full -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patch for 2.4.0 disable printk and panic messages, third try
Stefani Seibold wrote:
>
> Hi guys,
>
> this is now the third try to release my patch for disabling all kernel
> messages. It is usefull on deep embedded systems with no human interactions
> and for rescue discs where the diskspace is always to less.
>
> This patch has now the following features:
>
> The macro printk throws away all parameters and calls now a funciton "inline
> int printk_inline(void)" which always return 0 integer. So it should be now
> compatibel to the original printk funciton.
>
Then I suppose that you've checked that never in kernel printk arguments
have side effects, don't you ;-)
printk("%d", p());
printk("%d", a++);
etc.
You're changing semantics of a well known function and also if you don't
broke anything now, what grants this for the future?
You need also a big warning in printk documentation: "Note that
arguments may to be not evaluated" and hope everybody note it.
I'd prefer to rely on modern compiler smartness.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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 for 2.4.0 disable printk and panic messages, third try
Stefani Seibold wrote:
Hi guys,
this is now the third try to release my patch for disabling all kernel
messages. It is usefull on deep embedded systems with no human interactions
and for rescue discs where the diskspace is always to less.
This patch has now the following features:
The macro printk throws away all parameters and calls now a funciton "inline
int printk_inline(void)" which always return 0 integer. So it should be now
compatibel to the original printk funciton.
Then I suppose that you've checked that never in kernel printk arguments
have side effects, don't you ;-)
printk("%d", p());
printk("%d", a++);
etc.
You're changing semantics of a well known function and also if you don't
broke anything now, what grants this for the future?
You need also a big warning in printk documentation: "Note that
arguments may to be not evaluated" and hope everybody note it.
I'd prefer to rely on modern compiler smartness.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]
[EMAIL PROTECTED] wrote: > > > > The manpage disagrees with you: > > Do you jest? > > This manpages is wrong, or, to be more exact, is incomplete, > which is common flaw of them. > > get/set mean nothing but read-only/changing, i.e. > another important property missing in ioctl interface. setsockopt i.e. set socket options I think that Andrea's point is that SIOCPUSH don't set anything (i.e. don't change a state), but ask for an action to be done now. For this reason the name setsockopt is counter intuitive (apart from man page) and it seems to violate the principle of least surprise. I think this point of view is easily agreeable. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]
[EMAIL PROTECTED] wrote: The manpage disagrees with you: Do you jest? This manpages is wrong, or, to be more exact, is incomplete, which is common flaw of them. get/set mean nothing but read-only/changing, i.e. another important property missing in ioctl interface. setsockopt i.e. set socket options I think that Andrea's point is that SIOCPUSH don't set anything (i.e. don't change a state), but ask for an action to be done now. For this reason the name setsockopt is counter intuitive (apart from man page) and it seems to violate the principle of least surprise. I think this point of view is easily agreeable. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Before of all I want to publicly apologize with Richard as never my intention was to exacerbate him. > > On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote: > > asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is > > defined, otherwise it uses (take writel as an example) __raw_writel that > > IMHO need to be defined in core_t2.h. > > Perhaps you should _show_ an actual failure rather than just guessing. I've not access to this specific hardware but I was trying to fix the alpha case wrt write[bwlq] function as I've had a lot of trouble with ALSA drivers and 2.2 (that still now is broken wrt mb() and I've sent a patch to Alpha Processor guys). This is the reason why I've given a look to 2.4. > > You are wildly incorrect asserting that out of line functions are used > only with CONFIG_ALPHA_GENERIC. You should examine > > #ifndef __raw_writel > # define __raw_writel(v,a) ___raw_writel((v),(unsigned long)(a)) > #endif > > and suchlike definitions. Now I understand, thanks. I see that some core*.h leaves out of line some functions because they are more complex than a choosen threshold. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: > > On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote: > > ... the only missing things from core_t2.h are some defines to > > permit to it to work when CONFIG_ALPHA_T2 is defined. > > Have you tried it? I did. It works fine. > > What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to > define out of line functions that asm/io.h then uses. asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is defined, otherwise it uses (take writel as an example) __raw_writel that IMHO need to be defined in core_t2.h. core_t2.h is the only core_*.h file that does not define it and this is why I've proposed that patch. Perhaps there is a reason I don't understand and in this case I want to apologize and I'd like to ask you to explain me what I'm missing. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: > > On Sun, Dec 10, 2000 at 10:40:12AM +0100, Abramo Bagnara wrote: > > And this would be the only core_*.h files where this intention is > > expressed? > > Not at all. See core_lca.h, jensen.h, core_cia.h, core_mcpcia.h. I think you're confusing the issues: the only missing things from core_t2.h are some defines to permit to it to work when CONFIG_ALPHA_T2 is defined. The with or without mb() issue is handled in io.h and it's common for all cores. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: > > On Sat, Dec 09, 2000 at 09:43:00AM +0100, Abramo Bagnara wrote: > > alpha-mb-2.4.diff add missing defines from core_t2.h for non generic > > kernel (against 2.4.0test11) > > These are not "missing". They are intentionally not present > so that stuff will be done out of line. And this would be the only core_*.h files where this intention is expressed? It's hard to believe, without you explain why ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: On Sun, Dec 10, 2000 at 10:40:12AM +0100, Abramo Bagnara wrote: And this would be the only core_*.h files where this intention is expressed? Not at all. See core_lca.h, jensen.h, core_cia.h, core_mcpcia.h. I think you're confusing the issues: the only missing things from core_t2.h are some defines to permit to it to work when CONFIG_ALPHA_T2 is defined. The with or without mb() issue is handled in io.h and it's common for all cores. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Richard Henderson wrote: On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote: ... the only missing things from core_t2.h are some defines to permit to it to work when CONFIG_ALPHA_T2 is defined. Have you tried it? I did. It works fine. What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to define out of line functions that asm/io.h then uses. asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is defined, otherwise it uses (take writel as an example) __raw_writel that IMHO need to be defined in core_t2.h. core_t2.h is the only core_*.h file that does not define it and this is why I've proposed that patch. Perhaps there is a reason I don't understand and in this case I want to apologize and I'd like to ask you to explain me what I'm missing. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Before of all I want to publicly apologize with Richard as never my intention was to exacerbate him. On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote: asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is defined, otherwise it uses (take writel as an example) __raw_writel that IMHO need to be defined in core_t2.h. Perhaps you should _show_ an actual failure rather than just guessing. I've not access to this specific hardware but I was trying to fix the alpha case wrt write[bwlq] function as I've had a lot of trouble with ALSA drivers and 2.2 (that still now is broken wrt mb() and I've sent a patch to Alpha Processor guys). This is the reason why I've given a look to 2.4. You are wildly incorrect asserting that out of line functions are used only with CONFIG_ALPHA_GENERIC. You should examine #ifndef __raw_writel # define __raw_writel(v,a) ___raw_writel((v),(unsigned long)(a)) #endif and suchlike definitions. Now I understand, thanks. I see that some core*.h leaves out of line some functions because they are more complex than a choosen threshold. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [2*PATCH] alpha I/O access and mb()
Gérard Roudier wrote: > > > Based on that, let me claim that most of blind barriers inserted this way > are useless (thus sob-optimal) and may band-aid useful barriers that are > missing. The result is subtle bugs, hidden most of the time, that we will > have to suffer for decades. > > The only way to do things right regarding ordering it to have device > drivers _aware_ of such issues. Now, if we are happy with broken portable > or platform-independant drivers that rely on broken hidden ordering > alchemy rather than on correctness, then it is another story. I see perfectly your point and this is the reason why we have __raw_write[bwlq] in 2.4, but write[bwlq] expected semantic is to ensure that write *happens* and are visible by other agents. You can tell me that almost nobody uses __raw_write now and this is bad and I agree with you, but sometime this is not a perfect world ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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/
[2*PATCH] alpha I/O access and mb()
Here you are two patches:
alpha-mb-2.2.diff add the missing mb() to the cores that still lack it
(against 2.2.18pre25)
alpha-mb-2.4.diff add missing defines from core_t2.h for non generic
kernel (against 2.4.0test11)
Please apply on your trees.
I've also noted that 2.4 uses mb() after read[bwlq] while 2.2 don't.
Who's right?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
--- linux-2.2/include/asm-alpha/core_pyxis.h.~1~Tue Jan 4 19:12:24 2000
+++ linux-2.2/include/asm-alpha/core_pyxis.hSat Dec 9 09:17:43 2000
@@ -437,11 +437,13 @@
__EXTERN_INLINE void pyxis_bw_writel(unsigned int b, unsigned long addr)
{
*(vuip)(addr+PYXIS_BW_MEM) = b;
+ mb();
}
__EXTERN_INLINE void pyxis_bw_writeq(unsigned long b, unsigned long addr)
{
*(vulp)(addr+PYXIS_BW_MEM) = b;
+ mb();
}
__EXTERN_INLINE unsigned long pyxis_srm_base(unsigned long addr)
@@ -504,6 +506,7 @@
if (work) {
work += 0x00; /* add transfer length */
*(vuip) work = b * 0x01010101;
+ mb();
}
}
@@ -513,6 +516,7 @@
if (work) {
work += 0x08; /* add transfer length */
*(vuip) work = b * 0x00010001;
+ mb();
}
}
@@ -551,6 +555,7 @@
set_hae(msb);
*(vuip) ((addr << 5) + PYXIS_SPARSE_MEM + 0x00) = b * 0x01010101;
+ mb();
}
__EXTERN_INLINE void pyxis_writew(unsigned short b, unsigned long addr)
@@ -562,6 +567,7 @@
set_hae(msb);
*(vuip) ((addr << 5) + PYXIS_SPARSE_MEM + 0x08) = b * 0x00010001;
+ mb();
}
__EXTERN_INLINE unsigned long pyxis_readl(unsigned long addr)
@@ -577,11 +583,13 @@
__EXTERN_INLINE void pyxis_writel(unsigned int b, unsigned long addr)
{
*(vuip) (addr + PYXIS_DENSE_MEM) = b;
+ mb();
}
__EXTERN_INLINE void pyxis_writeq(unsigned long b, unsigned long addr)
{
*(vulp) (addr + PYXIS_DENSE_MEM) = b;
+ mb();
}
/* Find the DENSE memory area for a given bus address. */
--- linux-2.2/include/asm-alpha/core_apecs.h.~1~Mon Dec 28 00:21:50 1998
+++ linux-2.2/include/asm-alpha/core_apecs.hSat Dec 9 09:28:16 2000
@@ -543,6 +543,7 @@
set_hae(msb);
}
*(vuip) ((addr << 5) + APECS_SPARSE_MEM + 0x00) = b * 0x01010101;
+ mb();
}
__EXTERN_INLINE void apecs_writew(unsigned short b, unsigned long addr)
@@ -555,16 +556,19 @@
set_hae(msb);
}
*(vuip) ((addr << 5) + APECS_SPARSE_MEM + 0x08) = b * 0x00010001;
+ mb();
}
__EXTERN_INLINE void apecs_writel(unsigned int b, unsigned long addr)
{
*(vuip) (addr + APECS_DENSE_MEM) = b;
+ mb();
}
__EXTERN_INLINE void apecs_writeq(unsigned long b, unsigned long addr)
{
*(vulp) (addr + APECS_DENSE_MEM) = b;
+ mb();
}
/* Find the DENSE memory area for a given bus address. */
--- linux-2.2/include/asm-alpha/core_cia.h.~1~ Thu Aug 26 02:29:49 1999
+++ linux-2.2/include/asm-alpha/core_cia.h Sat Dec 9 09:28:16 2000
@@ -460,6 +460,7 @@
work += 0x00; /* add transfer length */
w = __kernel_insbl(b, addr & 3);
*(vuip) work = w;
+ mb();
}
}
@@ -470,6 +471,7 @@
work += 0x08; /* add transfer length */
w = __kernel_inswl(b, addr & 3);
*(vuip) work = w;
+ mb();
}
}
@@ -507,6 +509,7 @@
w = __kernel_insbl(b, addr & 3);
*(vuip) ((addr << 5) + CIA_SPARSE_MEM + 0x00) = w;
+ mb();
}
__EXTERN_INLINE void cia_writew(unsigned short b, unsigned long addr)
@@ -519,6 +522,7 @@
w = __kernel_inswl(b, addr & 3);
*(vuip) ((addr << 5) + CIA_SPARSE_MEM + 0x08) = w;
+ mb();
}
__EXTERN_INLINE unsigned long cia_readl(unsigned long addr)
@@ -534,11 +538,13 @@
__EXTERN_INLINE void cia_writel(unsigned int b, unsigned long addr)
{
*(vuip) (addr + CIA_DENSE_MEM) = b;
+ mb();
}
__EXTERN_INLINE void cia_writeq(unsigned long b, unsigned long addr)
{
*(vulp) (addr + CIA_DENSE_MEM) = b;
+ mb();
}
/* Find the DENSE memory area for a given bus address. */
--- linux-2.2/include/asm-alpha/core_t2.h.~1~ Mon Dec 28 00:21:50 1998
+++ linux-2.2/include/asm-alpha/core_t2.h Sat Dec 9 09:28:16 2000
@@ -499,6 +499,7 @@
if (work) {
work += 0x00; /* add transfer length */
*(vuip) work = b * 0x01010101;
+ mb();
}
}
@@ -508,6 +509,7 @@
if (work) {
work += 0x08; /* add transfer length */
*(vuip) work = b * 0x0001
[2*PATCH] alpha I/O access and mb()
Here you are two patches:
alpha-mb-2.2.diff add the missing mb() to the cores that still lack it
(against 2.2.18pre25)
alpha-mb-2.4.diff add missing defines from core_t2.h for non generic
kernel (against 2.4.0test11)
Please apply on your trees.
I've also noted that 2.4 uses mb() after read[bwlq] while 2.2 don't.
Who's right?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
--- linux-2.2/include/asm-alpha/core_pyxis.h.~1~Tue Jan 4 19:12:24 2000
+++ linux-2.2/include/asm-alpha/core_pyxis.hSat Dec 9 09:17:43 2000
@@ -437,11 +437,13 @@
__EXTERN_INLINE void pyxis_bw_writel(unsigned int b, unsigned long addr)
{
*(vuip)(addr+PYXIS_BW_MEM) = b;
+ mb();
}
__EXTERN_INLINE void pyxis_bw_writeq(unsigned long b, unsigned long addr)
{
*(vulp)(addr+PYXIS_BW_MEM) = b;
+ mb();
}
__EXTERN_INLINE unsigned long pyxis_srm_base(unsigned long addr)
@@ -504,6 +506,7 @@
if (work) {
work += 0x00; /* add transfer length */
*(vuip) work = b * 0x01010101;
+ mb();
}
}
@@ -513,6 +516,7 @@
if (work) {
work += 0x08; /* add transfer length */
*(vuip) work = b * 0x00010001;
+ mb();
}
}
@@ -551,6 +555,7 @@
set_hae(msb);
*(vuip) ((addr 5) + PYXIS_SPARSE_MEM + 0x00) = b * 0x01010101;
+ mb();
}
__EXTERN_INLINE void pyxis_writew(unsigned short b, unsigned long addr)
@@ -562,6 +567,7 @@
set_hae(msb);
*(vuip) ((addr 5) + PYXIS_SPARSE_MEM + 0x08) = b * 0x00010001;
+ mb();
}
__EXTERN_INLINE unsigned long pyxis_readl(unsigned long addr)
@@ -577,11 +583,13 @@
__EXTERN_INLINE void pyxis_writel(unsigned int b, unsigned long addr)
{
*(vuip) (addr + PYXIS_DENSE_MEM) = b;
+ mb();
}
__EXTERN_INLINE void pyxis_writeq(unsigned long b, unsigned long addr)
{
*(vulp) (addr + PYXIS_DENSE_MEM) = b;
+ mb();
}
/* Find the DENSE memory area for a given bus address. */
--- linux-2.2/include/asm-alpha/core_apecs.h.~1~Mon Dec 28 00:21:50 1998
+++ linux-2.2/include/asm-alpha/core_apecs.hSat Dec 9 09:28:16 2000
@@ -543,6 +543,7 @@
set_hae(msb);
}
*(vuip) ((addr 5) + APECS_SPARSE_MEM + 0x00) = b * 0x01010101;
+ mb();
}
__EXTERN_INLINE void apecs_writew(unsigned short b, unsigned long addr)
@@ -555,16 +556,19 @@
set_hae(msb);
}
*(vuip) ((addr 5) + APECS_SPARSE_MEM + 0x08) = b * 0x00010001;
+ mb();
}
__EXTERN_INLINE void apecs_writel(unsigned int b, unsigned long addr)
{
*(vuip) (addr + APECS_DENSE_MEM) = b;
+ mb();
}
__EXTERN_INLINE void apecs_writeq(unsigned long b, unsigned long addr)
{
*(vulp) (addr + APECS_DENSE_MEM) = b;
+ mb();
}
/* Find the DENSE memory area for a given bus address. */
--- linux-2.2/include/asm-alpha/core_cia.h.~1~ Thu Aug 26 02:29:49 1999
+++ linux-2.2/include/asm-alpha/core_cia.h Sat Dec 9 09:28:16 2000
@@ -460,6 +460,7 @@
work += 0x00; /* add transfer length */
w = __kernel_insbl(b, addr 3);
*(vuip) work = w;
+ mb();
}
}
@@ -470,6 +471,7 @@
work += 0x08; /* add transfer length */
w = __kernel_inswl(b, addr 3);
*(vuip) work = w;
+ mb();
}
}
@@ -507,6 +509,7 @@
w = __kernel_insbl(b, addr 3);
*(vuip) ((addr 5) + CIA_SPARSE_MEM + 0x00) = w;
+ mb();
}
__EXTERN_INLINE void cia_writew(unsigned short b, unsigned long addr)
@@ -519,6 +522,7 @@
w = __kernel_inswl(b, addr 3);
*(vuip) ((addr 5) + CIA_SPARSE_MEM + 0x08) = w;
+ mb();
}
__EXTERN_INLINE unsigned long cia_readl(unsigned long addr)
@@ -534,11 +538,13 @@
__EXTERN_INLINE void cia_writel(unsigned int b, unsigned long addr)
{
*(vuip) (addr + CIA_DENSE_MEM) = b;
+ mb();
}
__EXTERN_INLINE void cia_writeq(unsigned long b, unsigned long addr)
{
*(vulp) (addr + CIA_DENSE_MEM) = b;
+ mb();
}
/* Find the DENSE memory area for a given bus address. */
--- linux-2.2/include/asm-alpha/core_t2.h.~1~ Mon Dec 28 00:21:50 1998
+++ linux-2.2/include/asm-alpha/core_t2.h Sat Dec 9 09:28:16 2000
@@ -499,6 +499,7 @@
if (work) {
work += 0x00; /* add transfer length */
*(vuip) work = b * 0x01010101;
+ mb();
}
}
@@ -508,6 +509,7 @@
if (work) {
work += 0x08; /* add transfer length */
*(vuip) work = b * 0x00010001;
+ mb();
}
}
@@ -518,6 +520,7
Re: [2*PATCH] alpha I/O access and mb()
Gérard Roudier wrote: Based on that, let me claim that most of blind barriers inserted this way are useless (thus sob-optimal) and may band-aid useful barriers that are missing. The result is subtle bugs, hidden most of the time, that we will have to suffer for decades. The only way to do things right regarding ordering it to have device drivers _aware_ of such issues. Now, if we are happy with broken portable or platform-independant drivers that rely on broken hidden ordering alchemy rather than on correctness, then it is another story. I see perfectly your point and this is the reason why we have __raw_write[bwlq] in 2.4, but write[bwlq] expected semantic is to ensure that write *happens* and are visible by other agents. You can tell me that almost nobody uses __raw_write now and this is bad and I agree with you, but sometime this is not a perfect world ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: easy-to-fix bug in /dev/null driver
Michal Jaegermann wrote:
>
> On Tue, Nov 21, 2000 at 12:53:04AM +1030, Alan Kennington wrote:
> >
> > I still think that write_null() should be rewritten as:
> >
> > ===
> > static ssize_t write_null(struct file * file, const char * buf,
> > size_t count, loff_t *ppos)
> > {
> > return (count <= 2147483647) ? count : 2147483647;
> > }
> > ===
> >
> > This would fix the problem without introducing any new errors.
> > (Unless someone change the definitions of ssize_t and size_t!!)
>
> Someone already did. Or, more precisely, there are platforms where
> values used in 'return' above are bogus.
>
> Shifting 1 up by sizeof(ssize_t) * 8 - 1 and subtracting one from
> the result, in order to derive the maximal allowable value, might work.
> I do not think that we have anything with non-8 bit bytes yet.
>
I think it's time to provide SIZE_MAX and SSIZE_MAX along with
size_t/ssize_t typedefs.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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: easy-to-fix bug in /dev/null driver
Michal Jaegermann wrote:
On Tue, Nov 21, 2000 at 12:53:04AM +1030, Alan Kennington wrote:
I still think that write_null() should be rewritten as:
===
static ssize_t write_null(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
return (count = 2147483647) ? count : 2147483647;
}
===
This would fix the problem without introducing any new errors.
(Unless someone change the definitions of ssize_t and size_t!!)
Someone already did. Or, more precisely, there are platforms where
values used in 'return' above are bogus.
Shifting 1 up by sizeof(ssize_t) * 8 - 1 and subtracting one from
the result, in order to derive the maximal allowable value, might work.
I do not think that we have anything with non-8 bit bytes yet.
I think it's time to provide SIZE_MAX and SSIZE_MAX along with
size_t/ssize_t typedefs.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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: Linux's implementation of poll() not scalable?
Linus Torvalds wrote:
>
>
> struct event {
> int fd;
> unsigned long mask;
> void *opaque;
> void (*event_fn)(ind fd, unsigned long mask, void *opaque);
My experience say that:
unsigned long rmask;
void (*event_fn)(struct event *event);
is a far better solution (more type safe, more descriptive).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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: Linux's implementation of poll() not scalable?
Linus Torvalds wrote:
struct event {
int fd;
unsigned long mask;
void *opaque;
void (*event_fn)(ind fd, unsigned long mask, void *opaque);
My experience say that:
unsigned long rmask;
void (*event_fn)(struct event *event);
is a far better solution (more type safe, more descriptive).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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 to remove undefined C code
Bernd Schmidt wrote:
>
> +
> +#define ___swab64(x) \
> +({ \
> + __u64 __x = (x); \
> + ((__u64)( \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) << 56) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) << 40) | \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) << 24) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) << 8) | \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) >> 8) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) >> 24) | \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) >> 40) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) >> 56) )); \
> +})
Isn't this more efficient?
n = (x>>32) | (x<<32);
n = ((n & 0xLL)<<16) | (n & 0xffffLL)>>16;
n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8;
6 shift
4 and
3 or
instead of
8 shift
8 and
7 or
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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 to remove undefined C code
Bernd Schmidt wrote:
+
+#define ___swab64(x) \
+({ \
+ __u64 __x = (x); \
+ ((__u64)( \
+ (__u64)(((__u64)(__x) (__u64)0x00ffULL) 56) | \
+ (__u64)(((__u64)(__x) (__u64)0xff00ULL) 40) | \
+ (__u64)(((__u64)(__x) (__u64)0x00ffULL) 24) | \
+ (__u64)(((__u64)(__x) (__u64)0xff00ULL) 8) | \
+ (__u64)(((__u64)(__x) (__u64)0x00ffULL) 8) | \
+ (__u64)(((__u64)(__x) (__u64)0xff00ULL) 24) | \
+ (__u64)(((__u64)(__x) (__u64)0x00ffULL) 40) | \
+ (__u64)(((__u64)(__x) (__u64)0xff00ULL) 56) )); \
+})
Isn't this more efficient?
n = (x32) | (x32);
n = ((n 0xLL)16) | (n 0xLL)16;
n = ((n 0x00ff00ff00ff00ffLL)8) | (n 0xff00ff00ff00ff00LL)8;
6 shift
4 and
3 or
instead of
8 shift
8 and
7 or
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
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: [RFC] ioctl(2) return value
Alan Cox wrote: > > > I've looked Singe UNIX Specification, Version 2 and there this seems > > perfectly acceptable. > > > > I'd like very much to have some feedback to do the RightThing (tm). > > > > The alternative of course would be to add a result field inside struct > > passed by pointer to ioctl call. > > Linux doesnt care. If you want ALSA to run on SYS5 or BSD derived kernels you > should avoid returning anything but 0/error-code from ioctls. > I'd like you clarify the reasons for this choice in these OS families. Probably one of your gnomes knows it (I hope that this specific gnome is not in hibernation in this season :-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023 ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [RFC] ioctl(2) return value
Linus Torvalds wrote: > > On Thu, 21 Sep 2000, Abramo Bagnara wrote: > > > > In ALSA we use the return value from ioctl as a simple way to return a > > positive number to user space (if the return value is less than 0 we got > > error, of course) > > Looks fine to me. It's how most UNIX system calls work, I don't see why > ioctl() should be any different. > > Linus Cause my fault in sending to bad lkml address this answer has never reached the list. I'm sorry (now I've updated my address book). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023 ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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/
[RFC] ioctl(2) return value
In ALSA we use the return value from ioctl as a simple way to return a positive number to user space (if the return value is less than 0 we got error, of course) We got the doubt that this break some unknown standards or some linux conventions or Linus taste (at a first glance I'm unable to find precedents inside kernel tree). I've looked Singe UNIX Specification, Version 2 and there this seems perfectly acceptable. I'd like very much to have some feedback to do the RightThing (tm). The alternative of course would be to add a result field inside struct passed by pointer to ioctl call. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023 ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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/
[RFC] ioctl(2) return value
In ALSA we use the return value from ioctl as a simple way to return a positive number to user space (if the return value is less than 0 we got error, of course) We got the doubt that this break some unknown standards or some linux conventions or Linus taste (at a first glance I'm unable to find precedents inside kernel tree). I've looked Singe UNIX Specification, Version 2 and there this seems perfectly acceptable. I'd like very much to have some feedback to do the RightThing (tm). The alternative of course would be to add a result field inside struct passed by pointer to ioctl call. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023 ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: [RFC] ioctl(2) return value
Linus Torvalds wrote: On Thu, 21 Sep 2000, Abramo Bagnara wrote: In ALSA we use the return value from ioctl as a simple way to return a positive number to user space (if the return value is less than 0 we got error, of course) Looks fine to me. It's how most UNIX system calls work, I don't see why ioctl() should be any different. Linus Cause my fault in sending to bad lkml address this answer has never reached the list. I'm sorry (now I've updated my address book). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023 ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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/
