Secure boot and packaging third-party kernel modules

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 29/05/15 17:04, Simon Farnsworth wrote:
> On Friday 29 May 2015 15:24:24 David Sommerseth wrote:
>> 
>> On 28/05/15 23:03, David Smith wrote:
> <snip>
>>> But really the best solution here is to get the mhvtl kernel
>>> module upstream.
>> 
>> Agreed, but I'm not sure how keen upstream kernel developers are
>> to carry a driver for virtual tape devices.  I've asked mhvtl
>> upstream if that has been considered, but currently I'm not
>> convinced that will happen any time soon.
>> 
> As a different route, if upstream are still active, have they
> considered using LIO's TCMU interface[1]?
> 
> Combine this with tcm_loop to provide local access to the LIO SCSI
> targets, and it looks to provide the same featureset as mhvtl's
> kernel module, using existing kernel infrastructure. Note that I've
> not dived in deep enough to confirm that LIO is a competent
> solution here, but it looks like it provides the features mhvtl
> needs.
> 
> [1]
> https://www.kernel.org/doc/Documentation/target/tcmu-design.txt
> 

Thanks, Simon!  I'll check up on that!  I've not yet dug deep enough
into how the tape library is fully managed on the lower levels (I'm
still learning about how to make use of it).  But if this can replace
the mhvtl kernel module, that could perhaps simplify some of the work.

Very simply explained: mhvtl generates /dev/mhvtl device nodes which
is acting like tape robots.  And the user space tools mhvtl provides
is to "link" virtual tape drives/robots (via specific device nodes) to
files on a file system.  Then you can use ordinary tape tools (mt,
mtx, backup tools understanding tape drives, etc) to store data in
these files ... so the clue here is virtual tapes.  If LIO/TCM can
provide such support, then this might be a better solution.

But thanks a lot for the heads up!


- --
kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlVogsgACgkQIIWEatLf4Hc9FgCdEqyZ7gf0/sHFtQh2VzP/ujQF
cfUAoIn9xKetfbvHAtxOe31l8dZ5g44P
=ruwp
-----END PGP SIGNATURE-----