Re: [PATCH v7] drivers/staging: Gasket driver framework + Apex driver

[Alan Cox]

> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel
> framework is a generic, flexible system that supports thin kernel
> drivers. Gasket kernel drivers are expected to handle opening and
> closing devices, mmap'ing BAR space as requested, a small selection of
> ioctls, and handling page table translation (covered below). Any other
> functions should be handled by userspace code.

So it seems to me that we shouldn't have one random layer for Google
ASIC, another chunk of code for FPGA and so on. This all really ought to
be unified including where possible making things meaningfully self
describe.

You also don't seem to consider partitioning of an ASIC, eg if it
implements a serial port abstraction for debug that ought to routed to
the kernel, nor how to handle an ASIC that provides services to multiple
consumers ?

> One of the core assumptions of the Gasket framework is that precisely
> one process is allowed to have an open write handle to the device node
> at any given time. (That process may, once it has one write handle, open

Why ? That's a very un-Linuxlike and un-Unixlike model. It's more like
Windows and with all the problems we know that model causes.

> any number of additional write handles.) This is accomplished by
> tracking open and close data for each driver instance.

What if I want to have multiple threads not sharing an mm, or pass an
ASIC by handle to another instance - eg if I have a master process
assigning resources wanting to pass a handle into a container ?

And what about fd passing ?

It seems completely weird to try and do this given I can (given
permissions) equally just ptrace the person with it open and use ptrace
as a multiplexor ???


Also how about pointers to a real world use case example and user space ?

Alan