On Wed, Aug 10, 2005 at 11:07:01AM +0900, YAMAMOTO Takashi wrote:
> 
> i think you can use config(9) facilities to make any tape devices require
> the code.  (like wlan does)

Yes, that is true but the sticking point is the sysctl hooks.  At the
moment they refer to functions that are only defined if st.c is built,
I fixed that by including st.h which addressed the unresolved symbols
but I have subsequently found that there are some architectures that
have no scsipi at all so st.h is not generated.  A kernel build on
these architectures is now failing.

> i still don't understand why these tape-specific code is necessary, tho.
> 

Because they are not disk drives? because they don't have partitions?
They are not block devices?  Seeks are meaningless (even though these
are not tracked...).  I _could_ have put them in amongst the disks
but, really, they are a different class of device and thought it
better that they be treated a bit differently.

> 
> can you give me an example?
> 

kern/subr_disk.c:disk_unbusy is the one that worried me most, having
the kernel panic because the tape drive was unexpectedly busy seems a
bit harsh to me.  Maybe I am worrying too much.

> can't you solve it by adding some "if (tape)" conditions?
> 

If you know it is a tape drive - a new field would have to be added to
the disk struct or a flag passed to the function calls... and really
the calls should be renamed (and disk_subr.c) to drive_* instead of
disk_* since the names would be misleading.  I am not averse to doing
this, if it is seen as appropriate.

-- 
Brett Lymn