Re: [LSF/MM/BPF TOPIC] configfd as a replacement for both ioctls and fsconfig

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

 



On Tue, 2022-03-01 at 09:40 -0800, Luis Chamberlain wrote:
> On Tue, Mar 01, 2022 at 12:14:49PM -0500, James Bottomley wrote:
> > It looks fairly similar given the iouring syscalls are on an fd
> > except
> > that the structure above hash to be defined and becomes an
> > ABI.  Since
> > they configfd uses typed key value pairs, i'd argue it's more
> > generic
> > and introspectable.
> 
> I'm not suggesting using io-uring cmd as a configuration alternative
> to configfd, I'm suggesting it can be an async *vehicle* for a bunch
> of configurations one might need to make in the kernel. If we want
> to reduce system call uses, we may want to allow something like
> configfd to accept a batch of configuration options as well, as a
> batcha, and a final commit to process them.

Well, that's effectively how it does operate.  Configfd like configfs
is a dedicated fd you open exclusively for the purpose of
configuration.  You send it the key/value pairs via the action system
call.  Although the patch sent used "basic" types as values, nothing
prevents them being composite types that are aggregated, which would be
an easy mechanism for batching.

However, I'd like to add a note of caution: just because we *can* do
batching with the interface doesn't mean we should.  One of the
benefits of using simple basic types is easy interpretation by things
like seccomp; the more complex you make the type, the more internal
knowledge the seccomp/ebpf script needs.

So can I ask just how important batching for configuration changes is?
I get that there's some overhead for doing effectively one syscall per
k/v pair, but configuration operations aren't usually that time
critical.  If you're sending passthrough, then I can see you don't want
a load of syscalls per op, but equally a passthrough is just an opaque
packet that's likely not introspectable anyway, so it's a single k/v
pair.

James






[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux