[lkml]   [2021]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 10/16] ipmi: kcs bmc: Don't enforce single-ope n policy in the kernel

On Sat, 22 May 2021, at 03:00, Corey Minyard wrote:
> On Mon, May 10, 2021 at 03:12:07PM +0930, Andrew Jeffery wrote:
> > Soon it will be possible for one KCS device to have multiple associated
> > chardevs exposed to userspace (for IPMI and raw-style access). However,
> > don't prevent userspace from:
> >
> > 1. Opening more than one chardev at a time, or
> > 2. Opening the same chardev more than once.
> >
> > System behaviour is undefined for both classes of multiple access, so
> > userspace must manage itself accordingly.
> I don't understand why you want to allow this. If the second open won't
> work right, then why allow it? Why remove code that causes the second
> open to error?

Really I was just shifting the problem to userspace so it wasn't
something I needed to address in the kernel. It seems I'm alone in
thinking this is a good idea, as yourself, Zev, William and Joel
(privately) have pushed back against it. Initially the idea was tied up
in how I was doing some interrupt handling, but in revising the code
that problem has gone away.

I'll just drop this patch and save everyone the heartburn of arguing
about it :)


 \ /
  Last update: 2021-05-24 02:41    [W:0.123 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site