Clarification regarding design of a device.

Clarification regarding design of a device.

[mindentropy]

Hi,

   I have say a crypto device and if I pass a data stream assuming echo "test" 
> /dev/aes and when I read it I get an encrypted output. Now if a program 
opens the same device twice should and pass different streams should I 
differentiate those 2 streams and have encrypted buffers of these 2 streams as 
output? If yes how should I differentiate it? Or should I not differentiate and 
provide different devices say aes0,aes1 or should the userspace program worry 
about locking and sharing of resource?

Thanks.

Clarification regarding design of a device.

[Mulyadi Santosa]

Hi...

On Tue, May 3, 2011 at 00:23, mindentropy <mindentropy@gmail.com> wrote:
> Hi,
>
> ? I have say a crypto device and if I pass a data stream assuming echo "test"
>> /dev/aes and when I read it I get an encrypted output. Now if a program
> opens the same device twice should and pass different streams should I
> differentiate those 2 streams and have encrypted buffers of these 2 streams as
> output? If yes how should I differentiate it? Or should I not differentiate and
> provide different devices say aes0,aes1 or should the userspace program worry
> about locking and sharing of resource?

I am not keen regarding char/block device management, but I think you
should separate those streams.

How? Well, same thing like you open a same file twice, right? You're
given two different file descriptor. After all, the "open", "read" and
"write" handler of device IMHO always assume that we wanna achieve
such different stream, right?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Clarification regarding design of a device.

[mindentropy]

On Monday 02 May 2011 10:58:45 PM Mulyadi Santosa wrote:

> 
> I am not keen regarding char/block device management, but I think you
> should separate those streams.
> 
> How? Well, same thing like you open a same file twice, right? You're
> given two different file descriptor. After all, the "open", "read" and
> "write" handler of device IMHO always assume that we wanna achieve
> such different stream, right?

Although given two file descriptors when I write some content it will be on the 
same file right? Shouldn't the same file analogy apply?

I thought about using file descriptors to separate streams, but have to take 
care of ensuring completion of processing the buffer when closed.  This I feel 
should be done if the descriptor gets reused.

Clarification regarding design of a device.

[mindentropy]

On Monday 02 May 2011 10:58:45 PM Mulyadi Santosa wrote:
> 
> I am not keen regarding char/block device management, but I think you
> should separate those streams.
> 
> How? Well, same thing like you open a same file twice, right? You're
> given two different file descriptor. After all, the "open", "read" and
> "write" handler of device IMHO always assume that we wanna achieve
> such different stream, right?

Sounds silly but how do I get access to the file descriptor?

Also If I make the user create a session for an operation similar to this 
paper 
http://www.usenix.org/event/usenix03/tech/full_papers/keromytis/keromytis_html/node8.html#SECTION00042000000000000000, 
should I remove the read, write operations and do all operations using ioctl 
commands i.e. reading the user buffer etc?

Clarification regarding design of a device.

[Mulyadi Santosa]

Hi :)

On Fri, May 6, 2011 at 01:36, mindentropy <mindentropy@gmail.com> wrote:
>
> Sounds silly but how do I get access to the file descriptor?

to the best I know, kernel assign it for you and you access it from
the give file structure. For example, look at open handler
fs/proc/cpuinfo.c. You will see these:
static int cpuinfo_open(struct inode *inode, struct file *file)

Ok, I revise, perhaps not filedescriptor, but file structure itself.

> Also If I make the user create a session for an operation similar to this
> paper
> http://www.usenix.org/event/usenix03/tech/full_papers/keromytis/keromytis_html/node8.html#SECTION00042000000000000000,
> should I remove the read, write operations and do all operations using ioctl
> commands i.e. reading the user buffer etc?
>

There's a plus and minus of simply using ioctl for all read and write.
IMHO, ioctls are needed if you need various "sub command" toward the
device file, i.e if I took KVM for example: to setup new guest
structure, to ask for memory and so on. So, if you don't really need
to do such "extra" things, I believe it's better to still use
read/write handler for read/write operation.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com