Re: kern/43257: default SCSI-tape timeing parameters not selectable by kernel config

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

The following reply was made to PR kern/43257; it has been noted by GNATS.

From: Wolfgang.Stukenbrock%nagler-company.com@localhost
To: "Andrew Doran" <ad%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, 
Wolfgang.Stukenbrock%nagler-company.com@localhost
Subject: Re: kern/43257: default SCSI-tape timeing parameters not
        selectable by kernel config
Date: Thu, 13 May 2010 12:22:39 +0200

 Hi, again.
 
 If the parameters are settable during startup via sysctl.conf that would be
 nice and may obsolete the ability to change the "global" kernal defaults.
 But I think it does not hurt to make the kernel-defaults selecatable =20
 too as done at many other places too. (And that will enable the admin =20
 to work around tape-problems immediatly without other "still =20
 outstanding" kernel changes.)
 
 Neverless it would be very smart to have these parameters available on =20
 a per device basis. These parameters are of cause tape-device dependent.
 Accedently I have currently no idea how to integrate this.
 It is no sollution - my oppinion - to make them selectable via ioctl =20
 or something like this, because no "normal" backup-system would ever =20
 use them or have a usable stub to set them.
 It does not realy hurt to have such a feature, but it introduces some =20
 semantic problems:
 - when does a reset to the "default" values occure?
 -- on every close? -> need to set them after every open again - not usefull
 -- only with a special ioctl? -> possible unexpected side effects =20
 between different applications - may be problematic
 -- after disconnect/reconnect of the device - e.g. after Timeouts?
 
 The best way would be to use something like the sysctl interface for =20
 that - again my opinion.
 
 If it would be possible to distinguish between "global" defaults for =20
 all devices and device-specific defaults in the sysctl interface that =20
 should be sollution for this problem.
 Sun has such a feature by selecting the device in a first call and =20
 accessing it in additional calls, but this is problematic and if two =20
 processes try to use it at the same time, wrong information gets =20
 retrieved an/or set ...
 I don't know much about the possibilities of the sysctl-interface in =20
 NetBSD in respect of accessing device specific parameters. The set of =20
 devices will change over time due to connect/disconnect of devices =20
 (eg. USB or after "scsictl scan").
 I'm not shure if it would be a good idea to remember setting for =20
 device nodes accross disconnect/connect sequences. On the other hand, =20
 we will loose the setup for special devices after disconnect/connect =20
 if we drop them ...
 An other way may be to have different sets of default parameters =20
 depending on the device identification. But that requires more changes =20
 in the st-driver I think. And there must be an interface to control =20
 this during startup. (It makes no sence to have more than one set of =20
 default parameters compiled into the kernel. And to compile all setups =20
 statically into the kernel is not very user-friendly ...)
 
 Best reguards,
 
 W. Stukenbrock
 
 Zitat von "Andrew Doran" <ad%netbsd.org@localhost>:
 
 > On Thu, May 13, 2010 at 06:35:02AM +0000, David Holland wrote:
 >> The following reply was made to PR kern/43257; it has been noted by GNATS=
 .
 >>
 >> From: David Holland <dholland-bugs%netbsd.org@localhost>
 >> To: gnats-bugs%NetBSD.org@localhost
 >> Cc:
 >> Subject: Re: kern/43257: default SCSI-tape timeing parameters not
 >> =09selectable by kernel config
 >> Date: Thu, 13 May 2010 06:30:53 +0000
 >>
 >>  On Wed, May 05, 2010 at 12:30:04PM +0000, Andrew Doran wrote:
 >>   >  Thanks for the patch.  On the approach: these should be =20
 >> tuneable via sysctl
 >>   >  and not kernel options.
 >>
 >>  Shouldn't they be device properties?
 >
 > If the user can set them without recompiling the kernel, sure that
 > would work too.
 >
 >