[Fwd: Finger problem on Solaris with 2.2.4 (PR#24659)]

[David Lee]

On Mon, 17 Jun 2002, Jeremy Allison wrote:

> On Mon, Jun 17, 2002 at 12:24:34PM +0100, David Lee wrote:
> > 
> > So my trial implementation was:
> > 1. "smbd" to create/delete "/dev/smb/n" as a "named pipe";
> > 
> > 2. "smbd" then to include this in its "select()";
> > 
> > 3. anything appearing on "/dev/smb/n" to be sent to the client PC as a
> >    WinPopup, using code very similar (and potentially common) to
> >    "smbclient -M".
> > 
> > As a proof of concept it solved the "who" problem, and added this extra
> > wall/write functionality.
> 
> Unfortunately this is harder to do right than it appears. Even tridge
> created a bug when this was done for the select/kernel oplock code
> (it's finally fixed for 2.2.5).

I can believe that...  Being a Solaris site, I had noticed during the last
year of 2.2.x evolution that this area was relevant to those pernicious
oplock and avalanching problems whilst marvelling at the abilities of the
Samba Team to understand subtleties of the problems.

So my trials were only ever intended to be "proof of concept", and I
realised that this area in particular (events, select()) would need the
eagle-eyes and experience of the Samba Team. 

> To do this easily requires a proper "event" mechanism. I know how
> to do this, but currently lack the time to code it up.

Indeed.  In my tentative dabbling around that select(), I, too, thought
"this ideally needs a rationalised event handler". 

> IMHO we need the even[t] mechanism in smbd before we can start
> adding stuff like this.

Agreed.  But it would be nice to see the event mechanism in place!  Then
the rest of us could begin to code up our ideas.  This principle seems
roughly analogous to, and sympathetic with, other Samba developments, such
as the [cascading] VFS structure, and Andrew B's authentication work. 

I know that Andrew B. (and others?) have doubts about implementing various
aspects of this (create/delete "/dev/smb/n"; reading "/dev/smb/n") inside
"smbd".  I respect their concerns and their experience, and their
responsibilities as Samba-maintainers.

Could such an event mechanism be somehow linked to a plugin-like mechanism
(as with, for example: VFS and authentication)?  This would clearly
partition the responsibilities (core smbd v. plugin) while maintaining
relative ease of implementation, and maximising flexibility.

Best wishes.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :