[ale] Anyone here who is good with kernel programming?

[Michael B. Trausch]

On 02/12/2010 02:26 PM, Ed Cashin wrote:
> My intuition is that your problem is best solved in userspace,
> but if I'm wrong, there should be a specific reason---something
> that you can't do in userspace, like using some drive registers
> that are not accessible outside the kernel.

It is currently a veritable PITA to do things like get the capacity of a 
blank optical disc in userspace, which is the cornerstone of being able 
to robustly deal with certain types of users.  Granted, it's an ideal 
solution that I am going after, and I might have to kludge something 
together that is a _very_ temporary solution, but this whole process 
should be no more complex than:

# tar --create --multi-volume --file=/dev/sr0 /home
Prepare volume #2 for `/dev/sr0' and hit return:
Prepare volume #3 for `/dev/sr0' and hit return:
Prepare volume #4 for `/dev/sr0' and hit return:
Prepare volume #5 for `/dev/sr0' and hit return:
# _

Or even:

# do-home-backup
Prepare volume #2 for `/dev/sr0' and hit return:
Prepare volume #3 for `/dev/sr0' and hit return:
Prepare volume #4 for `/dev/sr0' and hit return:
Prepare volume #5 for `/dev/sr0' and hit return:
# _

(where do-home-backup is a script that simply runs the command above, 
because that's easier for a client to remember than the tar command).

> And if you can do it in userspace, rejoice!  It is much more
> challenging to program in the kernel than in userland.

Oh, yeah.  I'd love it if there were a way to do this in userland with 
tar.  I _can_ think of a way to do it in userland, kind-of-sort-of, but 
it would no longer involve using tar---what I'd have to do instead is 
probably write a special-purpose, non-portable program that writes 
multi-volume tar archives to optical media under Linux.  However, given 
that the driver already permits 'dd' to write to DVD-RAM media, I have 
to wonder how difficult it would be to permit it to write to non-RAM 
media as well, and just prohibit anything other than sequential writing 
to blank media.

> The kernelnewbies mailing list is a great place to ask questions
> like this, and there are some real experts that frequent that
> list from time to time.

I will have to check that out if trying packet writing does not work (or 
work well enough).  Thanks for the pointer!

> When you described the userland strategy of using multiple
> pseudoterminals, it sounded like yours might be a job for
> expect.  But I'm not really familiar enough with multi-volume
> tar archives and wodim to say.

I think expect would be able to do it.  I could, I think, do it with 
bash, dialog, expect, tar, and wodim.  However, it would be a rather 
rigid/fragile solution and I would see that as only a very short-term 
thing to be replaced with a better and more efficient solution.  Why 
involve 5+ processes when the job really should only require a single 
process doing a single thing?

I do think that the right place for the fix is in the kernel and to only 
have to lightly patch tar to learn how to determine the media size.

	--- Mike

-- 
Michael B. Trausch                    Blog: http://mike.trausch.us/blog/
Tel: (404) 592-5746 x1                            Email: mike at trausch.us