Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > Date: Thu, 12 Sep 2024 05:58:38 +0200
> > From: Denis Bodor <dbodor@lefinnois.net>
> > 
> > On Wed, Sep 11, 2024 at 04:57:41PM +0200, Mark Kettenis wrote:
> > > > This impacts a lot more code than I had originally thought.
> > > > I wonder if this is a good idea after all...
> > > Yes, not sure about this one.  The iic(4) bus itself does not support
> > > hotplugging and USB iic(4) controllers are somewhat of a rare toy I
> > > guess.
> > 
> > I know of two, the I2C-Tiny-USB project and the CP2112 controller...
> > I think this is only really useful if a /dev/iic-n is made available to
> > allow the buses to be used from user space.
> > 
> > There is the beginnings of such an implementation in i2c_io.h
> > (JI2C_IOCTL_EXEC behind a ‘#ifdef notyet’ ) but this code has been around
> > since 2004. Is this something desirable (notyet == tobedone) or is
> > the OpenBSD philosophy to keep access to i2c devices strictly in kernel
> > space?
> 
> I'd say the OpenBSD philosphy is to limit access to userland as much
> as possible.  We severely restrict access to GPIO pins already and
> there is significantly more damage one can do with raw access to I2C
> devices.  I don't see us implementing that ioctl, and we should
> probably remove the code from the header.

Yes

I'm going to stand firm on this.

if we don't know exactly what an IO device is, we don't make it available
to a user.  Period.