Re: [PATCH 2/3] config: values of pathname type can be prefixed with :(optional)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick Steinhardt <ps@xxxxxx> writes:

> I can see why it may be useful to allow for non-existent paths. But I
> wonder whether we really should be skipping over empty files, as well,
> as it may be assuming too much about the semantics of a given config
> key. In other words, are we reasonably sure that there won't ever be a
> usecase where you may want to specify an optional and empty file? And
> are there any use cases where an empty file should be ignored?

If somebody goes back to the original discussion that happened a few
years before the patches were originally written, they might find a
use case where it is more convenient to ignore an empty file, but it
is an old patch series, so I do not remember the details.

I would not be surprised if the design decision for an empty blob
was done without any deep thought or motivationg use case.  After
all, this was "I had nothing better to do, so wrote these out of
boredom" patchset, as its cover letter said.

If somebody wants to carry these patches forward (which I am hoping
because there were a few people who expressed interest recently, and
because I am not all that interested, certainly not more than those
who wanted to have this feature), I think that the right approach is
to extend the system by taking advantage of the syntax that was
designed to be extensible.  In addition to ":(optional)", we could
add different variants like ":(optional,ignore-empty)" with desired
semantics, for example.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux