[systemd-devel] [PATCH 2/2] tmpfiles: support globbing for w option
Dave Reisner
d at falconindy.com
Fri Sep 14 08:24:59 PDT 2012
On Tue, Sep 11, 2012 at 02:41:51PM +0200, Lennart Poettering wrote:
> On Mon, 10.09.12 22:42, Dave Reisner (d at falconindy.com) wrote:
>
> > > > 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...
> > >
> >
> > One atomic syscall sure -- and that't the point of writev. However, the
> > backend implementation is still of our concern. It obviously doesn't do
> > what we want. You actually want that the kernel changes its heuristics
> > on specific filesystems so that it modifies the behavior that userspace
> > explicitly requests? Sorry, but this seems entirely wrong to me.
>
> I don't follow. I am pretty sure the following two code snippets should
> have the very same effect on any fs:
>
> const char blob[] = "abcdef";
> write(fd, blob, 6);
>
> and:
>
> const char blob[] = "abcdef";
> struct iovec iov[2];
> iov[0].iov_base = blob;
> iov[0].iov_len = 3;
> iov[1].iov_base = blob + 3;
> iov[1].iov_len = 3;
> writev(fd, iov, 2);
>
> And they do have the same effect on most fs, except on sysfs. Now I am
> wondering whether this is somthing to fix in the kernel, or to just accept.
Sure, except sysfs isn't a filesystem with a concept of streams and
files like most other filesystems.
> Kay, Michal, you are kernel guys, what do you think about this?
fs/sysfs/file.c has this comment about sysfs_write_file():
/*
* <snip>
* There is no easy way for us to know if userspace is only doing a partial
* write, so we don't support them. We expect the entire buffer to come
* on the first write.
* Hint: if you're writing a value, first read the file, modify only the
* the value you're changing, then write entire buffer back.
*/
d
More information about the systemd-devel
mailing list