Re: UIO - interrupt performance
Ben Nizette wrote: On Mon, 2008-10-20 at 03:06 -0800, Nicholas Mc Guire wrote: On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote: We are contemplating porting a large number of device drivers to Linux. The pragmatic solution is to keep them in user mode (using the UIO framework) where possible ... they are written in C++ for a start. The obvious disadvantages of user mode device drivers are security / isolation. The main benefit is ease of development. Do you know what the *technical* disadvantages of this approach might be? I am most concerned about possible impact on interrupt handling. For example, I assume the context switching overhead is higher, and that interrupt latency is more difficult to predict? Userspace drivers certainly aren't first class citizens; uio and kernel mode drivers generally aren't really interchangeable. The technical disadvantages of userspace drivers are that you don't have access to kernel subsystems, you can't run any userspace content in irq context so everything needs to be scheduled before it can be dealt with. A UIO driver still needs a kernel component to do acknowledge the interrupt. As such when you say interrupt latency you need to define the end point. A UIO driver will have it's in-kernel handler called just as quickly as any other driver but the userspace app will need to be scheduled before it receives notification that the IRQ has fired. The technical advantage of a UIO driver is that devices which only need to shift data don't have to double-handle it. e.g. an ADC card doesn't need to move ADC results from hardware to kernel, kernel to userspace, it's just one fluid movement. What kind of device drivers are you talking about? They have to be of a fairly specific flavour to fit in to a UIO model. Linux isn't a microkernel, userspace drivers are quite restricted in their power. are these claims based on benchmarks of a specific driver ? I only know of a singe UIO driver for a Hilscher CIF card and one for a SMX Cryptengine (I guess thats yours any way) but none for a AD/DIO card - if you know of such a driver I would be interested in seeing its performance. When UIO was being discussed for inclusion, the example case being thrown around was for such an ADC card. They claimed to have seen significant improvements in speed by avoiding the double-handling of data. Come to think of it, I can't see that this specific driver has shown up... But what kind of benchmarks do you want? When I say restricted in their power I mean more in a feature-set kind of way than a raw speed way. Userspace drivers can't plug in to kernel subsystems so can't, for example, be SPI hosts or terminal devices or network hardware or anything else which sits in the middle of a standard stack. All they can do is be notified of an interrupt and have direct access to a lump of memory. As I asked before, what's your use-case? It tends to be fairly obvious whether the hardware is suitable for a UIO-based driver or whether it's going to have to live in kernel. Also if you know of any simple UIO sample drivers that would also help. As in examples of the userspace half? Unfortunately uio-smx isn't ready to fly thanks to some significant production delays but the userspace half of the Hilscher CIF driver can be found at http://www.osadl.org/projects/downloads/UIO/user/ As I see it, mainly the license conditions attract people to use UIO. Performance is not that important. Wolfgang. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
On Tue, 2008-10-21 at 08:57 +0200, Wolfgang Grandegger wrote: Ben Nizette wrote: As in examples of the userspace half? Unfortunately uio-smx isn't ready to fly thanks to some significant production delays but the userspace half of the Hilscher CIF driver can be found at http://www.osadl.org/projects/downloads/UIO/user/ As I see it, mainly the license conditions attract people to use UIO. Performance is not that important. Ohw god I hope not. If people want to keep their stuff proprietary they can supply binary-only modules a la nvidia. Thankfully such nonsense is fairly uncommon these days. UIO is not a set of hooks for general userspace drivers, it can't replace 99% of kernel drivers. It exists to allow easy and high-performance interfacing to a particular family of devices - those which simply need to shift data around and have an interrupt telling you when they're done. --Ben. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? --Ben. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
Ben Nizette wrote: On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. I known, fortunately it's not that simple or even feasible. Image a network driver with I/O multiplexing used by various processes. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to That's *not* an option, please read the GPL license conditions. At least it's legal gray area. Note that it's not my intention to start a discussion on that. a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? There will be plenty sooner than later. What you can do currently with UIO is very limited. Wolfgang. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
No I don't think you can decide kernel or user space, indeed you can read my previous posts, I quite agree with you, I meant the same to Bill Gatliff. Ben Nizette ha scritto: On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? --Ben. -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
Wolfgang Grandegger wrote: Ben Nizette wrote: On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. I known, fortunately it's not that simple or even feasible. Image a network driver with I/O multiplexing used by various processes. Actually, UIO is pretty useful for that when combined with tun/tap. That's *not* an option, please read the GPL license conditions. At least it's legal gray area. Note that it's not my intention to start a discussion on that. Then I will only contradict you, and not cite my supporting evidence. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
On Tue, 2008-10-21 at 02:12 +0100, Phillip Lougher wrote: David P. Quigley wrote: Looking through the code I see two references to xattrs, one is the index of the xattr table in the superblock and there seems to be struct member in one of the inode structures that is an index into this table. Looking through the code I don't see either of these used at all. Do you intend to add xattr support at some point? I saw reference to the desire to add xattr support in an email from 2004 but you said that the code has been rewritten since then. If you are going to add xattr support you probably want to add it to more than just regular files. In SELinux and other LSMs symlinks and directories are also labeled so they will need xattr entries. Yes and yes. I am intending to add xattr support, something that's been on my to-do list for a long time (since 2004 as you said), but it's been something which I've never got the time to do. Once (if) Squashfs is mainlined, it will be the next thing. The xattr references in the layout is my attempt at forward planning to avoid making an incompatible layout change when I finally get around to implementing it. My plan is to put xattrs in a table (referenced by the superblock), and then put indexes in extended inodes which index into the table (as you noticed). The general idea in Squashfs is that inodes get optimised for normally occurring cases, and less common cases (that would need a bigger inode) get to use an extended inode. Squashfs currently has an extended regular file inode, which is where the xattr index will sit, and so this has had an xattr index added. The other inodes don't currently have extended inodes, these will be defined when I implement xattrs (which is why they're missing). Having said that, I've fscked up and forgotten to add an xattr field to the extended directory inode which is currently defined :) Thanks for spotting this. Just to clarify: When using a labeled MAC solution like SELinux or SMACK, every file (of every type, including device nodes, symlinks, fifos, etc) will have a security attribute on it. In the case of ext3, we have benefited from inlining of small attributes into the inode. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 01/16] Squashfs: inode operations
On Fri, 2008-10-17 at 18:53 +0200, Jörn Engel wrote: None of the comments below are a reason against mainline inclusion, imo. They should get handled, but whether that happens before or after a merge doesn't really matter. On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote: +#include linux/squashfs_fs.h +#include linux/squashfs_fs_sb.h +#include linux/squashfs_fs_i.h Current verdict seems to be that these files should live in fs/squashfs/, not include/linux/. No kernel code beside squashfs needs the headers and userspace tools should have a private copy. [Snip] I looked at where filesystems such as ext3 store these and it seems to be in include/linux. I'm assuming this is because usespace utilities like fsck need them. It seems wrong for userspace tools to have their own private copy since you can potentially have them out of sync with the kernel you are running and it provides more chance for you forgetting to update a structure somewhere. Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 12/16] Squashfs: header files
On Fri, 2008-10-17 at 16:42 +0100, Phillip Lougher wrote:
[snip]
+
+struct squashfs_reg_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le32 start_block;
+ __le32 fragment;
+ __le32 offset;
+ __le32 file_size;
+ __le16 block_list[0];
+};
+
+struct squashfs_lreg_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le64 start_block;
+ __le64 file_size;
+ __le64 sparse;
+ __le32 nlink;
+ __le32 fragment;
+ __le32 offset;
+ __le32 xattr;
+ __le16 block_list[0];
+};
+
+struct squashfs_dir_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le32 start_block;
+ __le32 nlink;
+ __le16 file_size;
+ __le16 offset;
+ __le32 parent_inode;
+};
+
+struct squashfs_ldir_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le32 nlink;
+ __le32 file_size;
+ __le32 start_block;
+ __le32 parent_inode;
+ __le16 i_count;
+ __le16 offset;
+ struct squashfs_dir_index index[0];
+};
+
[snip]
Something that seems weird is the inconsistency in the ordering of these
structs. The base part is the same across all inodes but for your
reg/lreg dir/ldir pairs you seem to shuffle the order of the added
parts. Is there a reason for this? Is their layout the same on disk
(baring the extra data in the l versions)? If so they probably should be
the same in the struct.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 01/16] Squashfs: inode operations
On Tue, 21 October 2008 12:14:26 -0400, David P. Quigley wrote: On Fri, 2008-10-17 at 18:53 +0200, Jörn Engel wrote: None of the comments below are a reason against mainline inclusion, imo. They should get handled, but whether that happens before or after a merge doesn't really matter. On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote: +#include linux/squashfs_fs.h +#include linux/squashfs_fs_sb.h +#include linux/squashfs_fs_i.h Current verdict seems to be that these files should live in fs/squashfs/, not include/linux/. No kernel code beside squashfs needs the headers and userspace tools should have a private copy. [Snip] I looked at where filesystems such as ext3 store these and it seems to be in include/linux. I'm assuming this is because usespace utilities like fsck need them. It seems wrong for userspace tools to have their own private copy since you can potentially have them out of sync with the kernel you are running and it provides more chance for you forgetting to update a structure somewhere. Existing headers remain where they are. New headers are supposed to go... or at least that's what I was told to do. And being out of sync is definitely not an argument you can use with a filesystem. The data on your disk doesn't magically change when you upgrade a kernel. Nor can you assume that any given filesystem is accessed only by Linux. If you change the format, then locating external copies of the header will be the least of your problems. Jörn -- Do not stop an army on its way home. -- Sun Tzu -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 RESEND] gpiolib: Add pin change notification
On Tue, 21 Oct 2008 09:50:06 +1100
Ben Nizette [EMAIL PROTECTED] wrote:
This adds pin change notification to the gpiolib sysfs interface. It
requires 16 extra bytes in gpio_desc iff CONFIG_GPIO_SYSFS which in turn
means, eg, 4k of .bss usage on AVR32. Due to limitations in sysfs, this
patch makes poll(2) and friends work as expected on the value
attribute, though reads on value will never block and there is no
facility for async reads and writes.
...
+struct poll_desc *work_to_poll(struct work_struct *ws)
static
+{
+ return container_of((struct delayed_work *)ws, struct poll_desc, work);
+}
+
+void gpio_poll_work(struct work_struct *ws)
static
+{
+ struct poll_desc*poll = work_to_poll(ws);
+
+ unsignedgpio = poll-gpio;
+ struct gpio_desc*desc = gpio_desc[gpio];
+
+ int new = gpio_get_value_cansleep(gpio);
+ int old = desc-val;
+
+ if ((new !old test_bit(ASYNC_RISING, desc-flags)) ||
+ (!new old test_bit(ASYNC_FALLING, desc-flags)))
+ sysfs_notify(desc-dev-kobj, NULL, value);
+
+ desc-val = new;
+ schedule_delayed_work(poll-work, desc-timeout);
+}
+
+static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
+{
+ struct gpio_desc *desc = dev_id;
+ int gpio = desc - gpio_desc;
+ int new, old;
+
+ if (!gpio_is_valid(gpio))
+ return IRQ_NONE;
+
+ new = gpio_get_value(gpio);
+ old = desc-val;
+
+ if ((new !old test_bit(ASYNC_RISING, desc-flags)) ||
+ (!new old test_bit(ASYNC_FALLING, desc-flags)))
+ sysfs_notify(desc-dev-kobj, NULL, value);
eekeekeek! sysfs_notify() does mutex_lock() and will die horridly if
called from an interrupt handler.
You should have got a storm of warnings when runtime testing this code.
Please ensure that all debug options are enabled when testing code.
Documentation/SubmitChecklist has help.
+ desc-val = new;
+
+ return IRQ_HANDLED;
+}
+
static ssize_t gpio_direction_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -284,9 +351,162 @@ static ssize_t gpio_value_store(struct d
static /*const*/ DEVICE_ATTR(value, 0644,
gpio_value_show, gpio_value_store);
+static ssize_t gpio_notify_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t ret;
+
+ mutex_lock(sysfs_lock);
+
+ if (test_bit(ASYNC_MODE_IRQ, desc-flags))
+ ret = sprintf(buf, irq\n);
+ else if (test_bit(ASYNC_MODE_POLL, desc-flags))
+ ret = sprintf(buf, %ld\n, desc-timeout * 1000 / HZ);
+ else
+ ret = sprintf(buf, none\n);
+
+ mutex_unlock(sysfs_lock);
+ return ret;
+}
panics
oh, sysfs_lock is a gpiolib-local thing, not a sysfs-core thing.
Crappy name.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
On Wed, 2008-10-22 at 00:42 +0100, Phillip Lougher wrote: David P. Quigley wrote: Looking through the code I noticed that you give certain object types the same inode number for all instances of it (devices, fifo/sockets). How is this done internally? Do these types of objects occupy the same position on the inode table? If so how do you differentiate between a device and a socket? No, devices and fifo/sockets get their own unique inode numbers: [EMAIL PROTECTED]:/mnt# mount -t squashfs test.sqsh /mnt2 -o loop [EMAIL PROTECTED]:/mnt# ls -li /mnt2 total 0 2 crw-r--r-- 1 root root 1, 1 2008-10-22 00:31 device 4 prw-r--r-- 1 root root0 2008-10-22 00:31 fifo 3 srwxr-xr-x 1 root root0 2008-10-17 16:25 socket [Snip] My mistake I misread your statement in email 0. You said that squashfs has real inode numbers and that cramfs didn't. Good luck with your mainlining attempt. Once you get xattr support this would definitely make life better for people who want to make SELinux enabled LiveCDs and other small devices. Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
