re: CVS commit: src/sys/miscfs/specfs

[Paul Goyette]

On Thu, 8 Sep 2016, matthew green wrote:


"Paul Goyette" writes:

Module Name:src
Committed By:   pgoyette
Date:   Thu Sep  8 00:07:48 UTC 2016

Modified Files:
src/sys/miscfs/specfs: spec_vnops.c

Log Message:
if_config processing wants to auto-load modules named with an if_ prefix,
while specfc wants to auto-load modules without the prefix.  For modules
which can be loaded both ways (ie, if_tap and if_tun), provide a simple
conversion table for specfs so it can auto-load the if_ module.

This table should always be quite small, and the auto-load operation is
relatively infrequent, so the additional overhead of comparing names should
be tolerable.


would you mind reverting this and implementing the "dependant"
module model mlelstv proposed?

the above is a hack and doesn't scale or work if a new module
with the same "problem" is introduced, as it requires the base
kernel to be patched, where as a pair of modules can be added
much more easily.


Sure, I can do that.  Point well taken re requiring base kernel mods to 
add new table entries.


It will take me a couple of days to complete and test.  I've got a lot 
of issues dealing with my new machine...



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

re: CVS commit: src/sys/miscfs/specfs

[matthew green]

"Paul Goyette" writes:
> Module Name:  src
> Committed By: pgoyette
> Date: Thu Sep  8 00:07:48 UTC 2016
> 
> Modified Files:
>   src/sys/miscfs/specfs: spec_vnops.c
> 
> Log Message:
> if_config processing wants to auto-load modules named with an if_ prefix,
> while specfc wants to auto-load modules without the prefix.  For modules
> which can be loaded both ways (ie, if_tap and if_tun), provide a simple
> conversion table for specfs so it can auto-load the if_ module.
> 
> This table should always be quite small, and the auto-load operation is
> relatively infrequent, so the additional overhead of comparing names should
> be tolerable.

would you mind reverting this and implementing the "dependant"
module model mlelstv proposed?

the above is a hack and doesn't scale or work if a new module
with the same "problem" is introduced, as it requires the base
kernel to be patched, where as a pair of modules can be added
much more easily.

thanks.


.mrg.

Re: CVS commit: src/sys/miscfs/specfs

[Christos Zoulas]

In article <2015135437.b205bf...@cvs.netbsd.org>,
Paul Goyette  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  pgoyette
>Date:  Tue Dec 22 23:54:37 UTC 2015
>
>Modified Files:
>   src/sys/miscfs/specfs: spec_vnops.c
>
>Log Message:
>If we attempt to autoload a driver module, make sure we return an error
>if it fails.  Otherwise we might end up calling a builtin-but-disabled
>driver module and that can generate all sorts of issues...

Is there a reason to override the error?

christos

Re: CVS commit: src/sys/miscfs/specfs

[Paul Goyette]

On Wed, 23 Dec 2015, Christos Zoulas wrote:


In article <2015135437.b205bf...@cvs.netbsd.org>,
Paul Goyette  wrote:

-=-=-=-=-=-

Module Name:src
Committed By:   pgoyette
Date:   Tue Dec 22 23:54:37 UTC 2015

Modified Files:
src/sys/miscfs/specfs: spec_vnops.c

Log Message:
If we attempt to autoload a driver module, make sure we return an error
if it fails.  Otherwise we might end up calling a builtin-but-disabled
driver module and that can generate all sorts of issues...


Is there a reason to override the error?


No.  And since the error is already being reported, the change was
unneeded.

The bug I was following is elsewhere, so this change was backed out.


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: CVS commit: src/sys/miscfs/specfs

[J. Hannken-Illjes]

On 29 Jun 2015, at 18:47, David Holland dholland-sourcechan...@netbsd.org 
wrote:

 On Mon, Jun 29, 2015 at 12:25:49PM -0400, Christos Zoulas wrote:
 Module Name: src
 Committed By:christos
 Date:Mon Jun 29 16:25:49 UTC 2015
 
 Modified Files:
  src/sys/miscfs/specfs: spec_vnops.c
 
 Log Message:
 Revert previous, and explain why.
 
 Hrm, shouldn't it be vp?
 
 (as it is, it's using the uvm_object lock pointer as the key)

Yes, just changed the key to the address of vp-v_specdev which is
invariant over the lifetime of the vnode.

Coverity is quite cool ...

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: CVS commit: src/sys/miscfs/specfs

[David Holland]

On Mon, Jun 29, 2015 at 12:25:49PM -0400, Christos Zoulas wrote:
  Module Name: src
  Committed By:christos
  Date:Mon Jun 29 16:25:49 UTC 2015
  
  Modified Files:
   src/sys/miscfs/specfs: spec_vnops.c
  
  Log Message:
  Revert previous, and explain why.

Hrm, shouldn't it be vp?

(as it is, it's using the uvm_object lock pointer as the key)

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/sys/miscfs/specfs

[Antti Kantee]

On Tue Apr 13 2010 at 01:15:56 +, Adam Hoka wrote:
 Module Name:  src
 Committed By: ahoka
 Date: Tue Apr 13 01:15:56 UTC 2010
 
 Modified Files:
   src/sys/miscfs/specfs: spec_vnops.c
 
 Log Message:
 Autoload modules with any class.
 
 This fixes autoloading of pf, zfs and possibly others.

What is wrong with making drivers MODULE_CLASS_DRIVER?  I think we
should limit autoload aiming for safety, not splatter it all over.

Eventually everything will of course be fixed by, *tadaa*, devfs.
Meanwhile, please back this out and if you don't think calling a driver
a driver is the right thing to do, have a discussion.

Re: CVS commit: src/sys/miscfs/specfs

[Andrew Doran]

On Tue, Apr 13, 2010 at 10:47:51AM +0300, Antti Kantee wrote:
 On Tue Apr 13 2010 at 01:15:56 +, Adam Hoka wrote:
  Module Name:src
  Committed By:   ahoka
  Date:   Tue Apr 13 01:15:56 UTC 2010
  
  Modified Files:
  src/sys/miscfs/specfs: spec_vnops.c
  
  Log Message:
  Autoload modules with any class.
  
  This fixes autoloading of pf, zfs and possibly others.
 
 What is wrong with making drivers MODULE_CLASS_DRIVER?  I think we
 should limit autoload aiming for safety, not splatter it all over.
 
 Eventually everything will of course be fixed by, *tadaa*, devfs.
 Meanwhile, please back this out and if you don't think calling a driver
 a driver is the right thing to do, have a discussion.

What's the problem with autoloading any class?  Is it just a cosmetic thing?
One doesn't have to be an anointed driver to have an entry in /dev.

(It implies that the modules and devsw entries inhabit the same namespace.)

Re: CVS commit: src/sys/miscfs/specfs

[Andrew Doran]

On Tue, Apr 13, 2010 at 03:27:11PM +0300, Antti Kantee wrote:
 On Tue Apr 13 2010 at 12:18:38 +, Andrew Doran wrote:
  On Tue, Apr 13, 2010 at 10:47:51AM +0300, Antti Kantee wrote:
   On Tue Apr 13 2010 at 01:15:56 +, Adam Hoka wrote:
Module Name:src
Committed By:   ahoka
Date:   Tue Apr 13 01:15:56 UTC 2010

Modified Files:
src/sys/miscfs/specfs: spec_vnops.c

Log Message:
Autoload modules with any class.

This fixes autoloading of pf, zfs and possibly others.
   
   What is wrong with making drivers MODULE_CLASS_DRIVER?  I think we
   should limit autoload aiming for safety, not splatter it all over.
   
   Eventually everything will of course be fixed by, *tadaa*, devfs.
   Meanwhile, please back this out and if you don't think calling a driver
   a driver is the right thing to do, have a discussion.
  
  What's the problem with autoloading any class?  Is it just a cosmetic thing?
 
 I already mentioned my opinion above: aim for safety.  Since there
 is currently no common place to manage the different names we have,
 I don't want to discover some day that e.g. some secmodel name matches
 a devsw name.

So the kernel of the problem is namespace collisions, correct?

Would you agree that's it's the kernel programmers responsibility
to avoid conflicts?

If so how about sprinkling a little process in order to make it harder to
screw up?

Re: CVS commit: src/sys/miscfs/specfs

[Antti Kantee]

On Tue Apr 13 2010 at 12:32:38 +, Andrew Doran wrote:
 So the kernel of the problem is namespace collisions, correct?

Mostly.  Though I still think it's not expected that opening a /dev
node will load e.g. an exec package or secmodel even if that's what some
programmer wants.

 Would you agree that's it's the kernel programmers responsibility
 to avoid conflicts?
 
 If so how about sprinkling a little process in order to make it harder to
 screw up?

I'd say computers do conflict detection better.

Re: CVS commit: src/sys/miscfs/specfs

[Andrew Doran]

On Tue, Apr 13, 2010 at 03:40:24PM +0300, Antti Kantee wrote:
 On Tue Apr 13 2010 at 12:32:38 +, Andrew Doran wrote:
  So the kernel of the problem is namespace collisions, correct?
 
 Mostly.  Though I still think it's not expected that opening a /dev
 node will load e.g. an exec package or secmodel even if that's what some
 programmer wants.
 
  Would you agree that's it's the kernel programmers responsibility
  to avoid conflicts?
  
  If so how about sprinkling a little process in order to make it harder to
  screw up?
 
 I'd say computers do conflict detection better.

So the result of our teeth-pulling so far is:

1. You are concerned about namespace conflicts.  I am too.
2. I would be happy to see these managed through documentation and
   a straightforward approval process for adding modules.
3. You suggest that it would be better for the computer to manage it.

Can you suggest an alternative mechanism that will (a) allow us to
autoload things that are not anointed device drivers and (b) satisfy
your concerns?

As an example of something that wants autoloading both as a file
system and a driver, see ZFS.

Re: CVS commit: src/sys/miscfs/specfs

[Antti Kantee]

On Tue Apr 13 2010 at 13:25:24 +, Andrew Doran wrote:
 So the result of our teeth-pulling so far is:
 
 1. You are concerned about namespace conflicts.  I am too.
 2. I would be happy to see these managed through documentation and
a straightforward approval process for adding modules.

There is an additional pitfall with this.  We don't control all modules
and cannot be sure potential 3rd parties use the same processes.

 3. You suggest that it would be better for the computer to manage it.

Maybe not manage it, but at least detect it and fail gracefully.

 Can you suggest an alternative mechanism that will (a) allow us to
 autoload things that are not anointed device drivers and (b) satisfy
 your concerns?

devfs ;)

IOW, Given that we don't know where we most likely are in 6 months,
I'm not too keen on trying to spend energy to solve this right now ...

 As an example of something that wants autoloading both as a file
 system and a driver, see ZFS.

... if zfs is the only use case, since IIUC it's broken anyway.

Meanwhile, if there is something else which is catastrophically broken
due to lack of holy christening, we can revisit this and see if just
flipping the switch and maybe writing a simple audit script to verify
no collisions is the path of least wailing (this would be close to 2).

Re: CVS commit: src/sys/miscfs/specfs

[Masao Uebayashi]

On Tue, Apr 13, 2010 at 10:47 PM, Antti Kantee po...@cs.hut.fi wrote:
 On Tue Apr 13 2010 at 13:25:24 +, Andrew Doran wrote:
 So the result of our teeth-pulling so far is:

 1. You are concerned about namespace conflicts.  I am too.
 2. I would be happy to see these managed through documentation and
    a straightforward approval process for adding modules.

 There is an additional pitfall with this.  We don't control all modules
 and cannot be sure potential 3rd parties use the same processes.

 3. You suggest that it would be better for the computer to manage it.

 Maybe not manage it, but at least detect it and fail gracefully.

 Can you suggest an alternative mechanism that will (a) allow us to
 autoload things that are not anointed device drivers and (b) satisfy
 your concerns?

 devfs ;)

 IOW, Given that we don't know where we most likely are in 6 months,
 I'm not too keen on trying to spend energy to solve this right now ...

 As an example of something that wants autoloading both as a file
 system and a driver, see ZFS.

 ... if zfs is the only use case, since IIUC it's broken anyway.

 Meanwhile, if there is something else which is catastrophically broken
 due to lack of holy christening, we can revisit this and see if just
 flipping the switch and maybe writing a simple audit script to verify
 no collisions is the path of least wailing (this would be close to 2).

I like module names to become longer and unambiguous by making them
match the relative paths in src/sys, like sys/ufs/ffs/ffs.kmod.  I
don't think of any reason why module (driver, filesystem, ...) names
need to be very short.

Masao