Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

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

 



On Tue, Mar 01, 2022 at 08:47:47AM +0100, Arnd Bergmann wrote:
> On Mon, Feb 28, 2022 at 10:46 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> > On Tue, Feb 01, 2022 at 02:14:42AM +0000, Matthew Wilcox wrote:
> > > On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> > > You have to get it into each architecture.  Having a single place to
> > > add a new syscall would help reduce the number of places we use
> > > multiplexor syscalls like ioctl().
> >
> > Jeesh, is such a thing really possible? I wonder if Arnd has tried or
> > what he'd think...
> 
> Definitely possible, Firoz Khan was working on this at Linaro, but he
> never finished it before he left. I still have his patches if anyone wants
> to pick it up, though it might be easier to start over at this point.
> 
> The main work that is required here is to convert
> include/uapi/asm-generic/unistd.h into the syscall.tbl format,
> with a number of architecture specific conditionals to deal with all
> the combinations of syscalls that may or may not be used on a given
> target.
> 
> After that, I would modify the scripts/syscall*.sh scripts to allow
> multiple input files, splitting the architecture specific numbers
> (under 400) from the newer numbers (over 400) that can be
> shared between all architectures in a single location.

It is not a requirement for us, but this is good to know. Thanks!

  Luis



[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