On Mon, 03.09.12 23:25, Dave Reisner ([email protected]) wrote: > > On Mon, Sep 03, 2012 at 05:13:18PM -0400, Dave Reisner wrote: > > Break out the write logic into a separate function and simply use it as > > a callback to glob_item. > > > > This allows users to consolidate writes to sysfs with multiple similar > > pathnames, e.g. > > > > w /sys/class/block/sd[a-z]/queue/read_ahead_kb - - - - 1024 > > --- > > As is, and even without this patch, the example I point out won't work. > > I suspect this is a kernel bug, which I've reported: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=46981 > > > > Of course, I'm also happy to provide a workaround here, but I assume that > > systemd upstream would rather just have the kernel bug fixed. I haven't > > come across any other sysfs nodes (yet) that exhibit this broken behavior. > > Just to add to this, is there a particular reason writev was chosen?
One atomic syscall to write this string without copying any data, that's the advantage of the scatter/gather interfaces. Not that it would matter much in this case, but I guess it generally is a good habit using writev() where appropriate... > This is _always_ going to result in multiple writes, which sysfs won't > necessarily play nicely with [0]. Well, that sounds like as if writev was naively implemented in sysfs, no? Before we work around this in userspace I'd really like to see an attempt to get this fixed in the kernel... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
