interview question how does application connects to device

interview question how does application connects to device

[Bond]

This is an interview question.

I had written device driver for a char device so I know that code
structure looks like this

struct file_operations something {
?.owner=my_device_open;
?.read=my_device_read;
?.close=my_device_close;
?.write=my_device_write;

?}
When the device driver is active then in

/dev/mydevice
you can actually read and write into it. But what I was not clear is
how an application will read or write to this device. I know insmod
will insert the module to kernel,and register_chrdev(); will register
the driver in kernel but how will application program communicate with
this driver.


My answer was
In unix it simply opens the device node as a file and sends/receives
data and commands from it.

But he was expecting some thing more complex.

interview question how does application connects to device

[Prashant Shah]

Hi,

On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
> This is an interview question.
> My answer was
> In unix it simply opens the device node as a file and sends/receives
> data and commands from it.
>

A little more detailed method :

Userland read/write to the file -> Calls C Library read/write
functions -> Makes System Calls for read/write -> (now inside kernel)
-> Process the system calls (check parameter, etc) -> Refer the
file_operations structure for that file -> Call the corresponding
read/write function.

interview question how does application connects to device

[Bond]

On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
> Hi,
>
> On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
>> This is an interview question.
>> My answer was
>> In unix it simply opens the device node as a file and sends/receives
>> data and commands from it.
>>
>
> A little more detailed method :
>
> Userland read/write to the file -> Calls C Library read/write
> functions -> Makes System Calls for read/write -> (now inside kernel)
> -> Process the system calls (check parameter, etc) -> Refer the
> file_operations structure for that file -> Call the corresponding
> read/write function.
>

This is not correct.If you answer this in interview which I faced as I
did not get that job even you will not.
The answers on this mailing list did not helped.If you would have been
in the interview and given these answers it will not work.
Initially I posted the question on list I was expecting I missed some
thing or interviewer was blabbering more.But I gave 2-3 more
interviews
and all of them asked me same and I gave the answers which I learned
in this thread but I was not selected.

--

interview question how does application connects to device

[Anuz Pratap Singh Tomar]

On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:

> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com>
> wrote:
> > Hi,
> >
> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
> >> This is an interview question.
> >> My answer was
> >> In unix it simply opens the device node as a file and sends/receives
> >> data and commands from it.
> >>
> >
> > A little more detailed method :
> >
> > Userland read/write to the file -> Calls C Library read/write
> > functions -> Makes System Calls for read/write -> (now inside kernel)
> > -> Process the system calls (check parameter, etc) -> Refer the
> > file_operations structure for that file -> Call the corresponding
> > read/write function.
> >
>
> This is not correct.If you answer this in interview which I faced as I
> did not get that job even you will not.
> The answers on this mailing list did not helped.If you would have been
> in the interview and given these answers it will not work.
> Initially I posted the question on list I was expecting I missed some
> thing or interviewer was blabbering more.But I gave 2-3 more
> interviews
> and all of them asked me same and I gave the answers which I learned
> in this thread but I was not selected.
>
> --
>


This list is not an interview question answering mailing list.
Not getting selected have nothing to do with answers being right or wrong.
Being selected in an interview has a lot of other factors.



> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/3b78a686/attachment.html 

interview question how does application connects to device

[Bond]

On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar
<chambilkethakur@gmail.com> wrote:
>
>
> On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
>>
>> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
>> >> This is an interview question.
>> >> My answer was
>> >> In unix it simply opens the device node as a file and sends/receives
>> >> data and commands from it.
>> >>
>> >
>> > A little more detailed method :
>> >
>> > Userland read/write to the file -> Calls C Library read/write
>> > functions -> Makes System Calls for read/write -> (now inside kernel)
>> > -> Process the system calls (check parameter, etc) -> Refer the
>> > file_operations structure for that file -> Call the corresponding
>> > read/write function.
>> >
>>
>> This is not correct.If you answer this in interview which I faced as I
>> did not get that job even you will not.
>> The answers on this mailing list did not helped.If you would have been
>> in the interview and given these answers it will not work.
>> Initially I posted the question on list I was expecting I missed some
>> thing or interviewer was blabbering more.But I gave 2-3 more
>> interviews
>> and all of them asked me same and I gave the answers which I learned
>> in this thread but I was not selected.
>>
>> --
>
>
> This list is not an interview question answering mailing list.
> Not getting selected have nothing to do with answers being right or wrong.
> Being selected in an interview has a lot of other factors.
>
>
Why do not you understand that this has nothing to my selection what I
wanted to know is how does the app gets connected to device.And your
rant does not help to understand.The answers given on this list are of
very poor quality as usual.
As an example you rather than answering some thing meaningful reproduced rant.

interview question how does application connects to device

[Anuz Pratap Singh Tomar]

On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:

> On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar
> <chambilkethakur@gmail.com> wrote:
> >
> >
> > On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
> >>
> >> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com>
> wrote:
> >> >> This is an interview question.
> >> >> My answer was
> >> >> In unix it simply opens the device node as a file and sends/receives
> >> >> data and commands from it.
> >> >>
> >> >
> >> > A little more detailed method :
> >> >
> >> > Userland read/write to the file -> Calls C Library read/write
> >> > functions -> Makes System Calls for read/write -> (now inside kernel)
> >> > -> Process the system calls (check parameter, etc) -> Refer the
> >> > file_operations structure for that file -> Call the corresponding
> >> > read/write function.
> >> >
> >>
> >> This is not correct.If you answer this in interview which I faced as I
> >> did not get that job even you will not.
> >> The answers on this mailing list did not helped.If you would have been
> >> in the interview and given these answers it will not work.
> >> Initially I posted the question on list I was expecting I missed some
> >> thing or interviewer was blabbering more.But I gave 2-3 more
> >> interviews
> >> and all of them asked me same and I gave the answers which I learned
> >> in this thread but I was not selected.
> >>
> >> --
> >
> >
> > This list is not an interview question answering mailing list.
> > Not getting selected have nothing to do with answers being right or
> wrong.
> > Being selected in an interview has a lot of other factors.
> >
> >
> Why do not you understand that this has nothing to my selection what I
> wanted to know is how does the app gets connected to device.And your
> rant does not help to understand.The answers given on this list are of
> very poor quality as usual.
> As an example you rather than answering some thing meaningful reproduced
> rant.
>

Greg Freemyer answered your question with fine details. And the discussion
that followed elaborated the point.
But you say all that is NOT correct? on what basis did you say that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/9fd3cf40/attachment-0001.html 

interview question how does application connects to device

[Bond]

On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar
<chambilkethakur@gmail.com> wrote:
>
>
> On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
>>
>> On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar
>> <chambilkethakur@gmail.com> wrote:
>> >
>> >
>> > On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
>> >>
>> >> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com>
>> >> > wrote:
>> >> >> This is an interview question.
>> >> >> My answer was
>> >> >> In unix it simply opens the device node as a file and sends/receives
>> >> >> data and commands from it.
>> >> >>
>> >> >
>> >> > A little more detailed method :
>> >> >
>> >> > Userland read/write to the file -> Calls C Library read/write
>> >> > functions -> Makes System Calls for read/write -> (now inside kernel)
>> >> > -> Process the system calls (check parameter, etc) -> Refer the
>> >> > file_operations structure for that file -> Call the corresponding
>> >> > read/write function.
>> >> >
>> >>
>> >> This is not correct.If you answer this in interview which I faced as I
>> >> did not get that job even you will not.
>> >> The answers on this mailing list did not helped.If you would have been
>> >> in the interview and given these answers it will not work.
>> >> Initially I posted the question on list I was expecting I missed some
>> >> thing or interviewer was blabbering more.But I gave 2-3 more
>> >> interviews
>> >> and all of them asked me same and I gave the answers which I learned
>> >> in this thread but I was not selected.
>> >>
>> >> --
>> >
>> >
>> > This list is not an interview question answering mailing list.
>> > Not getting selected have nothing to do with answers being right or
>> > wrong.
>> > Being selected in an interview has a lot of other factors.
>> >
>> >
>> Why do not you understand that this has nothing to my selection what I
>> wanted to know is how does the app gets connected to device.And your
>> rant does not help to understand.The answers given on this list are of
>> very poor quality as usual.
>> As an example you rather than answering some thing meaningful reproduced
>> rant.
>
> Greg Freemyer answered your question with fine details. And the discussion
> that followed elaborated the point.
> But you say all that is NOT correct? on what basis did you say that?

I am reproducing what he answered

And the interviewer was right! You fell short.  And so did everyone
else in this thread.  I'm very surprised at the poor answers this
thread generated.  Maybe everyone should get a 20+ year old UNIX book
an read it so they know the basic and classic mechanisms.

My personal favorite old book was

 "The Magic Garden Explained: The Internals of Unix System V Release 4"

To my surprise Amazon has some copies.  New and used.  It's 20 years
old, but it will give some historical pre-linux context.  Remember
your interviewer is likely to be an old timer, so you need to be
familiar with classical UNIX, not just bleeding edge Linux.   (Not
that the answers showed familiarity with either, but the classic stuff
should pop of people's minds without thought.)

Back to the question

read / write are "data" paths, not control/status/command paths. Yes,
there are drivers that abuse read/write to handle commands, but they
are the exception, not the rule.

In general, read/write are termed in-band communications and using
them to communicate with ta driver is discouraged.  The Linux kernel
encourages out-of-band communications.

Let me simplify the question.

1) What are the FIVE classic system calls for interfacing with a
character device.  (ie. If it did not exist in 1970, don't list it).

2) Which of the 5 is still heavily used in the kernel but is
discouraged for new drivers being accepted into the linux kernel?

3) Name at least 3 alternatives that have been routinely used for
out-of-band communication in the Linux kernel since 2000.

Personally, anyone that can't answer those basic questions has failed
a job interview in my mind.


Let me know what do you understand from this.

--

interview question how does application connects to device

[Mulyadi Santosa]

On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
> Let me know what do you understand from this.


And Greg already kindly answer that for you too. Didn't you see his
answer? And why do you rant here anyway? Simply getting an answer
here, you already lucky and you should be thankful.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

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

interview question how does application connects to device

[Bond]

On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
>> Let me know what do you understand from this.
>
>
> And Greg already kindly answer that for you too. Didn't you see his
> answer? And why do you rant here anyway? Simply getting an answer
> here, you already lucky and you should be thankful.
>
> --
Let me know which part of answer answered as how application connects
to particular driver.I see answer explaining finer details of device
driver mehcanism but I did not see any where answer to original
question or if it has been answered I probably have been stupid enough
not to be able to
follow it.

interview question how does application connects to device

[Anuz Pratap Singh Tomar]

On Sun, Jul 17, 2011 at 6:34 PM, Bond <jamesbond.2k.g@gmail.com> wrote:

> On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
> >> Let me know what do you understand from this.
> >
> >
> > And Greg already kindly answer that for you too. Didn't you see his
> > answer? And why do you rant here anyway? Simply getting an answer
> > here, you already lucky and you should be thankful.
> >
> > --
> Let me know which part of answer answered as how application connects
> to particular driver.I see answer explaining finer details of device
> driver mehcanism but I did not see any where answer to original
> question or if it has been answered I probably have been stupid enough
> not to be able to
> follow it.
>
>
There have been a lot of discussion on udev and VFS and someone even
explained path of data flow from user space to kernel to end device.
you need to read more and read carefully. Besides your question is more
related to linux application programming and interface. Robert love's other
book(Linux system programming) should help you, there is one more book
Advanced linux programming, new riders publication.

P.S. And I really don't like tone of your mails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/e2694d25/attachment-0001.html 

interview question how does application connects to device

[Greg Freemyer]

On Sun, Jul 17, 2011 at 1:34 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
> On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
>> On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
>>> Let me know what do you understand from this.
>>
>>
>> And Greg already kindly answer that for you too. Didn't you see his
>> answer? And why do you rant here anyway? Simply getting an answer
>> here, you already lucky and you should be thankful.
>>
>> --
> Let me know which part of answer answered as how application connects
> to particular driver.I see answer explaining finer details of device
> driver mehcanism but I did not see any where answer to original
> question or if it has been answered I probably have been stupid enough
> not to be able to
> follow it.

Bond,

Here's a trivial userspace example.

What is the official userspace method for determining if a harddrive
is a traditional rotating disk, or a SSD?

I suspect you won't believe it, but it is just:

cat /sys/block/sda/queue/rotational.

What is the official userspace method for informing the kernel you
want to override its determination of rotating and set it to the SSD
setting?

echo 0 > /sys/block/sda/queue/rotational

Obviously you can code the userspace app for the above in any language you want.

The big thing is that the above is a simple userspace example of
userspace interfacing with the kernel via a formal abi.  Note I say
ABI not API.  ioctl changes in different architectures, so while it
can make a fine API, it is not a very good ABI.  That lack of
consistency in its ABI is one of the reasons it is discouraged.

sysfs is now the preferred solution for most basic userspace / kernel
interaction due to its simplicity and consistent ABI regardless of
platform / architecture.  You can see how almost trivially easy the
userspace side of the interface is.  You can also see that it is
exactly the same for a 32-bit app and for a 64-bit app.

You as a future kernel developer need to know how to write the kernel
side of the above.

As you do that, you will see that sysfs is designed for passing single
parameters back and forth.  If you have a need to pass multiple
parameters in a single atomic block, the sysfs is not the right
choice.  netlink sockets would be the most common recommended
interface for sending a collection of parameters at one time.  ie.
ioctl does the same by passing a structure pointer, but as I said
before ioctl is now discouraged.

Greg

interview question how does application connects to device

[Anuz Pratap Singh Tomar]

On Sun, Jul 17, 2011 at 4:52 PM, Bond <jamesbond.2k.g@gmail.com> wrote:

> On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar
> <chambilkethakur@gmail.com> wrote:
> >
> >
> > On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
> >>
> >> On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar
> >> <chambilkethakur@gmail.com> wrote:
> >> >
> >> >
> >> > On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com>
> wrote:
> >> >>
> >> >> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <
> pshah.mumbai at gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com>
> >> >> > wrote:
> >> >> >> This is an interview question.
> >> >> >> My answer was
> >> >> >> In unix it simply opens the device node as a file and
> sends/receives
> >> >> >> data and commands from it.
> >> >> >>
> >> >> >
> >> >> > A little more detailed method :
> >> >> >
> >> >> > Userland read/write to the file -> Calls C Library read/write
> >> >> > functions -> Makes System Calls for read/write -> (now inside
> kernel)
> >> >> > -> Process the system calls (check parameter, etc) -> Refer the
> >> >> > file_operations structure for that file -> Call the corresponding
> >> >> > read/write function.
> >> >> >
> >> >>
> >> >> This is not correct.If you answer this in interview which I faced as
> I
> >> >> did not get that job even you will not.
> >> >> The answers on this mailing list did not helped.If you would have
> been
> >> >> in the interview and given these answers it will not work.
> >> >> Initially I posted the question on list I was expecting I missed some
> >> >> thing or interviewer was blabbering more.But I gave 2-3 more
> >> >> interviews
> >> >> and all of them asked me same and I gave the answers which I learned
> >> >> in this thread but I was not selected.
> >> >>
> >> >> --
> >> >
> >> >
> >> > This list is not an interview question answering mailing list.
> >> > Not getting selected have nothing to do with answers being right or
> >> > wrong.
> >> > Being selected in an interview has a lot of other factors.
> >> >
> >> >
> >> Why do not you understand that this has nothing to my selection what I
> >> wanted to know is how does the app gets connected to device.And your
> >> rant does not help to understand.The answers given on this list are of
> >> very poor quality as usual.
> >> As an example you rather than answering some thing meaningful reproduced
> >> rant.
> >
> > Greg Freemyer answered your question with fine details. And the
> discussion
> > that followed elaborated the point.
> > But you say all that is NOT correct? on what basis did you say that?
>
> I am reproducing what he answered
>
> And the interviewer was right! You fell short.  And so did everyone
> else in this thread.  I'm very surprised at the poor answers this
> thread generated.  Maybe everyone should get a 20+ year old UNIX book
> an read it so they know the basic and classic mechanisms.
>
> My personal favorite old book was
>
>  "The Magic Garden Explained: The Internals of Unix System V Release 4"
>
> To my surprise Amazon has some copies.  New and used.  It's 20 years
> old, but it will give some historical pre-linux context.  Remember
> your interviewer is likely to be an old timer, so you need to be
> familiar with classical UNIX, not just bleeding edge Linux.   (Not
> that the answers showed familiarity with either, but the classic stuff
> should pop of people's minds without thought.)
>
> Back to the question
>
> read / write are "data" paths, not control/status/command paths. Yes,
> there are drivers that abuse read/write to handle commands, but they
> are the exception, not the rule.
>
> In general, read/write are termed in-band communications and using
> them to communicate with ta driver is discouraged.  The Linux kernel
> encourages out-of-band communications.
>
> Let me simplify the question.
>
> 1) What are the FIVE classic system calls for interfacing with a
> character device.  (ie. If it did not exist in 1970, don't list it).
>
> 2) Which of the 5 is still heavily used in the kernel but is
> discouraged for new drivers being accepted into the linux kernel?
>
> 3) Name at least 3 alternatives that have been routinely used for
> out-of-band communication in the Linux kernel since 2000.
>
> Personally, anyone that can't answer those basic questions has failed
> a job interview in my mind.
>
>
> Let me know what do you understand from this.
>
> --
>


For one he is pointing out that there are more mechanism to interact with
devices than just read/write.
When you open a device node, you do not have to necessarily read or write.
In most cases its not ever required
The drivers implement many methods like proc, ioctls, the new sysfs each of
which can be directly read from or write to or pass some control/command.
For example network drivers don't have device nodes, netlink interface or
sockets is used to interact with them.
Secondly he is pointing out the fact that some of the interfaces are being
deprecated like sysfs will be used for most purpose as compared to proc.
In between this discussion, it was also pointed out that seek() call may not
be useful for character drivers and its not one of the most important one.
another way for interacting with kernel could be using mmap(). I do not
exactly remember how it works, but it has been explained here on this list
many times.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/4e184765/attachment.html 

interview question how does application connects to device

[Bond]

On Sun, Jul 17, 2011 at 9:44 PM, Anuz Pratap Singh Tomar
<chambilkethakur@gmail.com> wrote:
>
>
> On Sun, Jul 17, 2011 at 4:52 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
>>
>> On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar
>> <chambilkethakur@gmail.com> wrote:
>> >
>> >
>> > On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
>> >>
>> >> On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar
>> >> <chambilkethakur@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah
>> >> >> <pshah.mumbai@gmail.com>
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com>
>> >> >> > wrote:
>> >> >> >> This is an interview question.
>> >> >> >> My answer was
>> >> >> >> In unix it simply opens the device node as a file and
>> >> >> >> sends/receives
>> >> >> >> data and commands from it.
>> >> >> >>
>> >> >> >
>> >> >> > A little more detailed method :
>> >> >> >
>> >> >> > Userland read/write to the file -> Calls C Library read/write
>> >> >> > functions -> Makes System Calls for read/write -> (now inside
>> >> >> > kernel)
>> >> >> > -> Process the system calls (check parameter, etc) -> Refer the
>> >> >> > file_operations structure for that file -> Call the corresponding
>> >> >> > read/write function.
>> >> >> >
>> >> >>
>> >> >> This is not correct.If you answer this in interview which I faced as
>> >> >> I
>> >> >> did not get that job even you will not.
>> >> >> The answers on this mailing list did not helped.If you would have
>> >> >> been
>> >> >> in the interview and given these answers it will not work.
>> >> >> Initially I posted the question on list I was expecting I missed
>> >> >> some
>> >> >> thing or interviewer was blabbering more.But I gave 2-3 more
>> >> >> interviews
>> >> >> and all of them asked me same and I gave the answers which I learned
>> >> >> in this thread but I was not selected.
>> >> >>
>> >> >> --
>> >> >
>> >> >
>> >> > This list is not an interview question answering mailing list.
>> >> > Not getting selected have nothing to do with answers being right or
>> >> > wrong.
>> >> > Being selected in an interview has a lot of other factors.
>> >> >
>> >> >
>> >> Why do not you understand that this has nothing to my selection what I
>> >> wanted to know is how does the app gets connected to device.And your
>> >> rant does not help to understand.The answers given on this list are of
>> >> very poor quality as usual.
>> >> As an example you rather than answering some thing meaningful
>> >> reproduced
>> >> rant.
>> >
>> > Greg Freemyer answered your question with fine details. And the
>> > discussion
>> > that followed elaborated the point.
>> > But you say all that is NOT correct? on what basis did you say that?
>>
>> I am reproducing what he answered
>>
>> And the interviewer was right! You fell short. ?And so did everyone
>> else in this thread. ?I'm very surprised at the poor answers this
>> thread generated. ?Maybe everyone should get a 20+ year old UNIX book
>> an read it so they know the basic and classic mechanisms.
>>
>> My personal favorite old book was
>>
>> ?"The Magic Garden Explained: The Internals of Unix System V Release 4"
>>
>> To my surprise Amazon has some copies. ?New and used. ?It's 20 years
>> old, but it will give some historical pre-linux context. ?Remember
>> your interviewer is likely to be an old timer, so you need to be
>> familiar with classical UNIX, not just bleeding edge Linux. ? (Not
>> that the answers showed familiarity with either, but the classic stuff
>> should pop of people's minds without thought.)
>>
>> Back to the question
>>
>> read / write are "data" paths, not control/status/command paths. Yes,
>> there are drivers that abuse read/write to handle commands, but they
>> are the exception, not the rule.
>>
>> In general, read/write are termed in-band communications and using
>> them to communicate with ta driver is discouraged. ?The Linux kernel
>> encourages out-of-band communications.
>>
>> Let me simplify the question.
>>
>> 1) What are the FIVE classic system calls for interfacing with a
>> character device. ?(ie. If it did not exist in 1970, don't list it).
>>
>> 2) Which of the 5 is still heavily used in the kernel but is
>> discouraged for new drivers being accepted into the linux kernel?
>>
>> 3) Name at least 3 alternatives that have been routinely used for
>> out-of-band communication in the Linux kernel since 2000.
>>
>> Personally, anyone that can't answer those basic questions has failed
>> a job interview in my mind.
>>
>>
>> Let me know what do you understand from this.
>>
>> --
>
>
> For one he is pointing out that there are more mechanism to interact with
> devices than just read/write.
> When you open a device node, you do not have to necessarily read or write.
> In most cases its not ever required
> The drivers implement many methods like proc, ioctls, the new sysfs each of
> which can be directly read from or write to or pass some control/command.
> For example network drivers don't have device nodes, netlink interface or
> sockets is used to interact with them.
> Secondly he is pointing out the fact that some of the interfaces are being
> deprecated like sysfs will be used for most purpose as compared to proc.
> In between this discussion, it was also pointed out that seek() call may not
> be useful for character drivers and its not one of the most important one.
> another way for interacting with kernel could be using mmap(). I do not
> exactly remember how it works, but it has been explained here on this list
> many times.
>
What I simply want to know is what is the mechanism that application
connects to particular device driver and I am not able to understand
if this has been answered.I know drivers have methods etc etc but how
does application connects to them that is what I want to know.

interview question how does application connects to device

[Philipp Ittershagen]

On 07/05/2011 06:15 AM, Bond wrote:
> But he was expecting some thing more complex.

Well, to be honest, I also was expecting something more complex when I
first looked at kernel programming and creating character devices ;) But
the file_operations interface is really straight-forward and simple,
very nice.


Philipp

interview question how does application connects to device

[Paraneetharan Chandrasekaran]

I think the thread originator is asking about how the application knows
which device file to read or write.
This is done by h/w management system udev. udev creates/manages device
nodes in /dev/ dir and notifes applications based on the udev rules written
(via HAL events or DBUS signals).

Thanks,
Paraneetharan C


On 5 July 2011 12:21, Philipp Ittershagen <lists@gate-nine.de> wrote:

> On 07/05/2011 06:15 AM, Bond wrote:
> > But he was expecting some thing more complex.
>
> Well, to be honest, I also was expecting something more complex when I
> first looked at kernel programming and creating character devices ;) But
> the file_operations interface is really straight-forward and simple,
> very nice.
>
>
> Philipp
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Regards,
Paraneetharan C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/cba31b88/attachment.html 

interview question how does application connects to device

[Mandeep Sandhu]

On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran
<paraneetharanc@gmail.com> wrote:
> I think the thread originator is asking about how the application knows
> which device file to read or write.
> This is done by h/w management system udev. udev creates/manages device
> nodes in /dev/ dir and notifes applications based on the udev rules written
> (via HAL events or DBUS signals).

I don't think udev is involved in the read/write file ops. Udev is
responsible for handling hotplug events, doing certain actions based
on events (as indicated by udev rules),persistent naming of devices
etc...but not file i/o.

That, I think, is handled by the VFS layer. Each device node is
uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS
layer uses this to pick the correct file-ops struct to communicate
with the device. So when we try to open a device, say /devtyyS0, it's
major-minor numbers

My info is a little dated, so plz CMIIW.

HTH,
-mandeep

interview question how does application connects to device

[Mandeep Sandhu]

Oops, accidentally pressed send...

On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu
<mandeepsandhu.chd@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran
> <paraneetharanc@gmail.com> wrote:
>> I think the thread originator is asking about how the application knows
>> which device file to read or write.
>> This is done by h/w management system udev. udev creates/manages device
>> nodes in /dev/ dir and notifes applications based on the udev rules written
>> (via HAL events or DBUS signals).
>
> I don't think udev is involved in the read/write file ops. Udev is
> responsible for handling hotplug events, doing certain actions based
> on events (as indicated by udev rules),persistent naming of devices
> etc...but not file i/o.
>
> That, I think, is handled by the VFS layer. Each device node is
> uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS
> layer uses this to pick the correct file-ops struct to communicate
> with the device.

Eg; when we try to open a device, say /dev/ttyS0, it's major-minor
numbers (eg: 64-4 on my machine) are used to lookup the file-ops
struct and from then on, the VFS passes the read/write calls to this
device driver.

HTH,
-mandeep
>
> My info is a little dated, so plz CMIIW.
>
> HTH,
> -mandeep
>

interview question how does application connects to device

[Abhijit Pawar]

On 5 July 2011 13:01, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:

> Oops, accidentally pressed send...
>
> On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu
> <mandeepsandhu.chd@gmail.com> wrote:
> > On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran
> > <paraneetharanc@gmail.com> wrote:
> >> I think the thread originator is asking about how the application knows
> >> which device file to read or write.
> >> This is done by h/w management system udev. udev creates/manages device
> >> nodes in /dev/ dir and notifes applications based on the udev rules
> written
> >> (via HAL events or DBUS signals).
> >
> > I don't think udev is involved in the read/write file ops. Udev is
> > responsible for handling hotplug events, doing certain actions based
> > on events (as indicated by udev rules),persistent naming of devices
> > etc...but not file i/o.
> >
> > That, I think, is handled by the VFS layer. Each device node is
> > uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS
> > layer uses this to pick the correct file-ops struct to communicate
> > with the device.
>
> >Eg; when we try to open a device, say /dev/ttyS0, it's major-minor
> >numbers (eg: 64-4 on my machine) are used to lookup the file-ops
> >struct and from then on, the VFS passes the read/write calls to this
> >device driver.
>

Yes. whenever we read or write to the device, the file operations structure
would be invoked for the device. And this device is identified by the Major
and Minor number combination.
The device driver / kernel module at registration time mention what major
and minor it would be servicing.

This is what I think it should work. Good to get confirmation though.

Regards,
Abhijit

>
> HTH,
> -mandeep
> >
> > My info is a little dated, so plz CMIIW.
> >
> > HTH,
> > -mandeep
> >
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/d6d31f80/attachment-0001.html 

interview question how does application connects to device

[er krishna]

On Tue, Jul 5, 2011 at 1:21 PM, Abhijit Pawar <apawar.linux@gmail.com>wrote:

>
>
> On 5 July 2011 13:01, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
>
>> Oops, accidentally pressed send...
>>
>> On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu
>> <mandeepsandhu.chd@gmail.com> wrote:
>> > On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran
>> > <paraneetharanc@gmail.com> wrote:
>> >> I think the thread originator is asking about how the application knows
>> >> which device file to read or write.
>> >> This is done by h/w management system udev. udev creates/manages device
>> >> nodes in /dev/ dir and notifes applications based on the udev rules
>> written
>> >> (via HAL events or DBUS signals).
>> >
>> > I don't think udev is involved in the read/write file ops. Udev is
>> > responsible for handling hotplug events, doing certain actions based
>> > on events (as indicated by udev rules),persistent naming of devices
>> > etc...but not file i/o.
>> >
>> > That, I think, is handled by the VFS layer. Each device node is
>> > uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS
>> > layer uses this to pick the correct file-ops struct to communicate
>> > with the device.
>>
>> >Eg; when we try to open a device, say /dev/ttyS0, it's major-minor
>> >numbers (eg: 64-4 on my machine) are used to lookup the file-ops
>> >struct and from then on, the VFS passes the read/write calls to this
>> >device driver.
>>
>
> Yes. whenever we read or write to the device, the file operations structure
> would be invoked for the device. And this device is identified by the Major
> and Minor number combination.
> The device driver / kernel module at registration time mention what major
> and minor it would be servicing.
>
> This is what I think it should work. Good to get confirmation though.
>

Udev creates the device node and loads the corresponding driver based on the
major/minor no. So after this step udev is out of the picture and control
goes on particular device node and then file-operation will come into
picture for read and write. It will try to read the data from cache (buffer
cache) and if not avilable there then from disk...


>
> Regards,
> Abhijit
>
>>
>> HTH,
>> -mandeep
>> >
>> > My info is a little dated, so plz CMIIW.
>> >
>> > HTH,
>> > -mandeep
>> >
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/3c26c3a7/attachment.html 

interview question how does application connects to device

[Mandeep Sandhu]

> picture for read and write. It will try to read the data from cache (buffer
> cache) and if not avilable there then from disk...

This is applicable only for block devices, not for all devices (eg: char dev).

-mandeep

interview question how does application connects to device

[er krishna]

On Tue, Jul 5, 2011 at 2:43 PM, Mandeep Sandhu
<mandeepsandhu.chd@gmail.com>wrote:

> > picture for read and write. It will try to read the data from cache
> (buffer
> > cache) and if not avilable there then from disk...
>
> This is applicable only for block devices, not for all devices (eg: char
> dev).
>
Yep...100% true....

>
> -mandeep
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/7766b422/attachment.html 

interview question how does application connects to device

[Greg Freemyer]

On Tue, Jul 5, 2011 at 12:15 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
> This is an interview question.
>
> I had written device driver for a char device so I know that code
> structure looks like this
>
> struct file_operations something {
> ?.owner=my_device_open;
> ?.read=my_device_read;
> ?.close=my_device_close;
> ?.write=my_device_write;
>
> ?}
> When the device driver is active then in
>
> /dev/mydevice
> you can actually read and write into it. But what I was not clear is
> how an application will read or write to this device. I know insmod
> will insert the module to kernel,and register_chrdev(); will register
> the driver in kernel but how will application program communicate with
> this driver.
>
>
> My answer was
> In unix it simply opens the device node as a file and sends/receives
> data and commands from it.
>
> But he was expecting some thing more complex.

And the interviewer was right! You fell short.  And so did everyone
else in this thread.  I'm very surprised at the poor answers this
thread generated.  Maybe everyone should get a 20+ year old UNIX book
an read it so they know the basic and classic mechanisms.

My personal favorite old book was

  "The Magic Garden Explained: The Internals of Unix System V Release 4"

To my surprise Amazon has some copies.  New and used.  It's 20 years
old, but it will give some historical pre-linux context.  Remember
your interviewer is likely to be an old timer, so you need to be
familiar with classical UNIX, not just bleeding edge Linux.   (Not
that the answers showed familiarity with either, but the classic stuff
should pop of people's minds without thought.)

Back to the question

read / write are "data" paths, not control/status/command paths. Yes,
there are drivers that abuse read/write to handle commands, but they
are the exception, not the rule.

In general, read/write are termed in-band communications and using
them to communicate with ta driver is discouraged.  The Linux kernel
encourages out-of-band communications.

Let me simplify the question.

1) What are the FIVE classic system calls for interfacing with a
character device.  (ie. If it did not exist in 1970, don't list it).

2) Which of the 5 is still heavily used in the kernel but is
discouraged for new drivers being accepted into the linux kernel?

3) Name at least 3 alternatives that have been routinely used for
out-of-band communication in the Linux kernel since 2000.

Personally, anyone that can't answer those basic questions has failed
a job interview in my mind.

Greg

interview question how does application connects to device

[Mandeep Sandhu]

> Let me simplify the question.

I'll attempt to answer your questions...for my own edification! :)

>
> 1) What are the FIVE classic system calls for interfacing with a
> character device. ?(ie. If it did not exist in 1970, don't list it).

open/close/read/write/seek?...and the infamous ioctl.
>
> 2) Which of the 5 is still heavily used in the kernel but is
> discouraged for new drivers being accepted into the linux kernel?

I'm guessing this is ioctl's...because now the preferred way to
communicate/give commands to a device is via sysfs?
>
> 3) Name at least 3 alternatives that have been routinely used for
> out-of-band communication in the Linux kernel since 2000.

ioctl's, profs/sysfs, netlink sockets maybe?

Thanks,
-mandeep

interview question how does application connects to device

[Greg Freemyer]

On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu
<mandeepsandhu.chd@gmail.com> wrote:
>> Let me simplify the question.
>
> I'll attempt to answer your questions...for my own edification! :)
>
>>
>> 1) What are the FIVE classic system calls for interfacing with a
>> character device. ?(ie. If it did not exist in 1970, don't list it).
>
> open/close/read/write/seek?...and the infamous ioctl.

You listed 6.  Historically character devices don't seek.  So drop
that one to get to 5.

(And yes, you can find char devices that implement seek, but ioctl is
far more common.  And when I learned UNIX 30 years ago, it was just
the basic 5 I'm pretty sure that actually have matching driver code..)

That is, drivers don't implement seek.  seek() just sets a offset
variable tracked in the kernel.  The driver is not even woken up when
the happens.

That is if userspace did:

open()
seek(1)
seek(2)
seek(3)
write()

The driver would get invoked for open, and again for write.  When
write is invoked, the offset field would have a 3 in it.  The driver
has no way to even know seek(1) and seek(2) calls were made.

So if you read a kernel book, you'll find seek() gets very little
attention.  It's really just a glorified way to say offset=value;

>> 2) Which of the 5 is still heavily used in the kernel but is
>> discouraged for new drivers being accepted into the linux kernel?
>
> I'm guessing this is ioctl's...because now the preferred way to
> communicate/give commands to a device is via sysfs?

Correct, ioctl is no longer preferred, but it is definitely still
used.  And the ext4 team is still adding new ioctl commands despite it
being discouraged.

(I don't know why they are able to do that, but I know they do.)


>> 3) Name at least 3 alternatives that have been routinely used for
>> out-of-band communication in the Linux kernel since 2000.
>
> ioctl's, profs/sysfs, netlink sockets maybe?

Yes, except procfs and sysfs are 2 different solutions, so you named 4.

As of 2011, both ioctl's and procfs are discouraged for new "device driver" use.

ioctl's will likely be around forever just because there are so many
legacy ioctl implementations that need to be supported.  Think of
stty.  That is a hugely complex ioctl based tool that I seriously
doubt ever gets rewritten with a new kernel interface.

procfs on they other hand will hopefully lose all the non-process
specific users, but keep the process specific ones.  That is, the
current preference is /proc should only have info related to running
processes, not all the other miscellaneous stuff.  I don?t think there
is yet an effort to remove those other files, but hopefully there will
be gone at some point.

One thing to keep in mind is that anything that interfaces with
userspace is part of the kernel ABI and becomes very hard to change /
get rid of.

That actually means that any patches / driver submissions that impact
on the kernel / userspace interface get a extra hard look.

It also means a perspective employer will want to make sure you really
understand the userspace / kernel interface.  It is just too hard to
throw out a implementation once accepted by LKML.  Even in a embedded
world where the driver is not sent upstream you want the kernel ABI to
be as stable as possible.  Otherwise you have to always be ensuring
your kernel and userspace apps are compatible versions.

>
> Thanks,
> -mandeep
>

Hope that helps at least someone in a future interview
Greg

interview question how does application connects to device

[Abhijit Pawar]

On 5 July 2011 21:33, Greg Freemyer <greg.freemyer@gmail.com> wrote:

> On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu
> <mandeepsandhu.chd@gmail.com> wrote:
> >> Let me simplify the question.
> >
> > I'll attempt to answer your questions...for my own edification! :)
> >
> >>
> >> 1) What are the FIVE classic system calls for interfacing with a
> >> character device.  (ie. If it did not exist in 1970, don't list it).
> >
> > open/close/read/write/seek?...and the infamous ioctl.
>
> You listed 6.  Historically character devices don't seek.  So drop
> that one to get to 5.
>
> (And yes, you can find char devices that implement seek, but ioctl is
> far more common.  And when I learned UNIX 30 years ago, it was just
> the basic 5 I'm pretty sure that actually have matching driver code..)
>
> That is, drivers don't implement seek.  seek() just sets a offset
> variable tracked in the kernel.  The driver is not even woken up when
> the happens.
>
> That is if userspace did:
>
> open()
> seek(1)
> seek(2)
> seek(3)
> write()
>
> The driver would get invoked for open, and again for write.  When
> write is invoked, the offset field would have a 3 in it.  The driver
> has no way to even know seek(1) and seek(2) calls were made.
>
> So if you read a kernel book, you'll find seek() gets very little
> attention.  It's really just a glorified way to say offset=value;
>
> >> 2) Which of the 5 is still heavily used in the kernel but is
> >> discouraged for new drivers being accepted into the linux kernel?
> >
> > I'm guessing this is ioctl's...because now the preferred way to
> > communicate/give commands to a device is via sysfs?
>
> Correct, ioctl is no longer preferred, but it is definitely still
> used.  And the ext4 team is still adding new ioctl commands despite it
> being discouraged.
>
> (I don't know why they are able to do that, but I know they do.)
>
>
> >> 3) Name at least 3 alternatives that have been routinely used for
> >> out-of-band communication in the Linux kernel since 2000.
> >
> > ioctl's, profs/sysfs, netlink sockets maybe?
>
> Yes, except procfs and sysfs are 2 different solutions, so you named 4.
>
> As of 2011, both ioctl's and procfs are discouraged for new "device driver"
> use.
>
> ioctl's will likely be around forever just because there are so many
> legacy ioctl implementations that need to be supported.  Think of
> stty.  That is a hugely complex ioctl based tool that I seriously
> doubt ever gets rewritten with a new kernel interface.
>
> procfs on they other hand will hopefully lose all the non-process
> specific users, but keep the process specific ones.  That is, the
> current preference is /proc should only have info related to running
> processes, not all the other miscellaneous stuff.  I don?t think there
> is yet an effort to remove those other files, but hopefully there will
> be gone at some point.
>
> One thing to keep in mind is that anything that interfaces with
> userspace is part of the kernel ABI and becomes very hard to change /
> get rid of.
>
> That actually means that any patches / driver submissions that impact
> on the kernel / userspace interface get a extra hard look.
>
> It also means a perspective employer will want to make sure you really
> understand the userspace / kernel interface.  It is just too hard to
> throw out a implementation once accepted by LKML.  Even in a embedded
> world where the driver is not sent upstream you want the kernel ABI to
> be as stable as possible.  Otherwise you have to always be ensuring
> your kernel and userspace apps are compatible versions.
>
> >
> > Thanks,
> > -mandeep
> >
>
> >Hope that helps at least someone in a future interview
>

This is good. One more addition from my side which is not necessarily the
answer to Greg's question: Bottom Halves are discouraged now days in driver.


> Greg
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110706/11d4b948/attachment.html 

interview question how does application connects to device

[Prashant Shah]

Hi,

On Wed, Jul 6, 2011 at 9:38 AM, Abhijit Pawar <apawar.linux@gmail.com> wrote:
>
> This is good. One more addition from my side which is not necessarily the
> answer to Greg's question: Bottom Halves are discouraged now days in driver.

then what are the alternatives ? are there any articles or
documentation for it ?

interview question how does application connects to device

[Abhijit Pawar]

On 6 July 2011 10:13, Prashant Shah <pshah.mumbai@gmail.com> wrote:

> Hi,
>
> On Wed, Jul 6, 2011 at 9:38 AM, Abhijit Pawar <apawar.linux@gmail.com>
> wrote:
> >
> > This is good. One more addition from my side which is not necessarily the
> > answer to Greg's question: Bottom Halves are discouraged now days in
> driver.
>
> then what are the alternatives ? are there any articles or
> documentation for it ?
>
Tasklets or workqueues. Please refer to LDD3 chapter 10.  I should have
written that older bottom halves are not supported. my mistake.

Regards,
Abhijit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110706/3b9d7080/attachment-0001.html 

interview question how does application connects to device

[StephanT]

Hi all,

----- Original Message -----
> From: Greg Freemyer <greg.freemyer@gmail.com>


> 
> Correct, ioctl is no longer preferred, but it is definitely still
> used.? And the ext4 team is still adding new ioctl commands despite it
> being discouraged.
> 


If ioctl is no longer preferred what is its preferred alternative ?

Could you, please explain why ioctl felt in disgrace.


Thanks,
Stephan.

interview question how does application connects to device

[Greg KH]

On Mon, Jul 11, 2011 at 10:43:50AM -0700, StephanT wrote:
> Hi all,
> 
> ----- Original Message -----
> > From: Greg Freemyer <greg.freemyer@gmail.com>
> 
> 
> > 
> > Correct, ioctl is no longer preferred, but it is definitely still
> > used.? And the ext4 team is still adding new ioctl commands despite it
> > being discouraged.
> > 
> 
> 
> If ioctl is no longer preferred what is its preferred alternative ?

a virtual filesystem, sysfs, debugfs, configfs, or something else is
usually all you need.  As mentioned, netlink is also a good alternative,
and so is the connector interface.

> Could you, please explain why ioctl felt in disgrace.

It's essencially adding a brand new system call every single time,
32/64bit problems, pointer problems, structure problems, incorrect
bounds checking almost always happens and other nastyness.

That being said, there are still times when ioctl is the correct thing
to use, but you have to really know what you are doing and be able to
justify it.

hope this helps,

greg k-h

interview question how does application connects to device

[Greg Freemyer]

On Mon, Jul 11, 2011 at 1:43 PM, StephanT <stman937-linewbie@yahoo.com> wrote:
> Hi all,
>
> ----- Original Message -----
>> From: Greg Freemyer <greg.freemyer@gmail.com>
>
>
>>
>> Correct, ioctl is no longer preferred, but it is definitely still
>> used.? And the ext4 team is still adding new ioctl commands despite it
>> being discouraged.
>>
>
>
> If ioctl is no longer preferred what is its preferred alternative ?

For simple tasks related to processes procfs.  (I think procfs is read
only from user space)

For simple tasks related to devices sysfs  (sysfs is read / write from
userspace, but uses very simple data formats.  No structures as an
example.

For complex controls, netlink sockets:
http://www.linuxjournal.com/article/7356 is a 5 year article I found
with a quick grep.

> Could you, please explain why ioctl felt in disgrace.

I really don't recall the details, but I'm almost positive I've seen
new patches rejected because they were based on ioctl's.

Can someone else please confirm I'm not imagining things.

As I recall, it has to do with the various architectures not being
easily handled by the ioctl ABI.

==> Here's one quote I just found from lkml Feb. 2010

Can you describe what your driver is doing? One rule of thumb
is that if you already require a character device, using ioctl
is the right answer, but you shouldn't create a character device
if all you want to do over it is a single ioctl operation.

        Arnd
===

Greg

interview question how does application connects to device

[Mandeep Sandhu]

> How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS.
>
> For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose.

Franlky, I've never used the sysfs interface and mostly know it from
'theoretical' view-point. It was created mostly for providing a
uniform way for user-space applications (udev/HAL, driver tools, etc)
to interact with a device driver. It exposes the underlying device
topology as a directory tree.

I'm not sure how sysfs applies to 'filesystem' as it depicts a
particular 'device hierarchy tree' within a kernel. As Greg mentioned
here, lot filesystem drivers still prefer to use the ioctl interface.
However, one use for it which I can see, is for controlling the
underlying block device (hard-disk, USB mass storage etc).

HTH,
-mandeep

interview question how does application connects to device

[Javier Martinez Canillas]

2011/7/6 Mandeep Sandhu <mandeepsandhu.chd@gmail.com>:
>> How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS.
>>
>> For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose.
>

Something that always has caught my attention is why netlink sockets
are so popular. I know that ioctl is deprecated and all new kernel
code that needs full-duplex communication between userspace and
kernelspace shoud use netlink as its interface.

But one of the arguments against ioctl is that you don't have type
checking which makes really hard to audit the parameters passed from
userspace. Also ioctl can be provided by third party as modules (that
can also be proprietary binary only ones) which even complicates more
to have a general security mechanism.

My question is, why netlink sockets are better than ioctls? It is not
yet another interface to use as a wildcard to pass any data you wan't
between the kernel and userpace with the only difference that you use
another paradigm? (network sockets with a specific protocol family
instead file operations over a device).

Sorry if my question is stupid but I just don't get the point.

Regards,

-- 
Javier Mart?nez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Aut?noma de Barcelona
Barcelona, Spain

interview question how does application connects to device

[Greg Freemyer]

2011/7/6 Javier Martinez Canillas <martinez.javier@gmail.com>:
> 2011/7/6 Mandeep Sandhu <mandeepsandhu.chd@gmail.com>:
>>> How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS.
>>>
>>> For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose.
>>
>
> Something that always has caught my attention is why netlink sockets
> are so popular. I know that ioctl is deprecated and all new kernel
> code that needs full-duplex communication between userspace and
> kernelspace shoud use netlink as its interface.
>
> But one of the arguments against ioctl is that you don't have type
> checking which makes really hard to audit the parameters passed from
> userspace. Also ioctl can be provided by third party as modules (that
> can also be proprietary binary only ones) which even complicates more
> to have a general security mechanism.
>
> My question is, why netlink sockets are better than ioctls? It is not
> yet another interface to use as a wildcard to pass any data you wan't
> between the kernel and userpace with the only difference that you use
> another paradigm? (network sockets with a specific protocol family
> instead file operations over a device).
>
> Sorry if my question is stupid but I just don't get the point.
>
> Regards,
>
> --
> Javier Mart?nez Canillas
> (+34) 682 39 81 69
> PhD Student in High Performance Computing
> Computer Architecture and Operating System Department (CAOS)
> Universitat Aut?noma de Barcelona
> Barcelona, Spain
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

Javier,

I think the main issue with ioctl is that with some architectures, the
userspace and kernel compiler treat 64-bit structure members
differently, so it is very easy to create a structure which can not
easily be passed via a simple pointer in-all-architectures.

With netlink sockets, one is expected to have a well defined byte
order coming across the socket.

Greg

interview question how does application connects to device

[Javier Martinez Canillas]

>> My question is, why netlink sockets are better than ioctls? It is not
>> yet another interface to use as a wildcard to pass any data you wan't
>> between the kernel and userpace with the only difference that you use
>> another paradigm? (network sockets with a specific protocol family
>> instead file operations over a device).
>>
>> Sorry if my question is stupid but I just don't get the point.
>>
>> Regards,
>>
> Javier,
>
> I think the main issue with ioctl is that with some architectures, the
> userspace and kernel compiler treat 64-bit structure members
> differently, so it is very easy to create a structure which can not
> easily be passed via a simple pointer in-all-architectures.
>
> With netlink sockets, one is expected to have a well defined byte
> order coming across the socket.
>
> Greg
>

Greg,

Thank you very much for your answer, I wasn't aware of that ioctl limitation.

Best regards,

-- 
Javier Mart?nez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Aut?noma de Barcelona
Barcelona, Spain

interview question how does application connects to device

[Shaz]

On Tue, Jul 5, 2011 at 9:15 AM, Bond <jamesbond.2k.g@gmail.com> wrote:

> This is an interview question.
>
> I had written device driver for a char device so I know that code
> structure looks like this
>
> struct file_operations something {
>  .owner=my_device_open;
>  .read=my_device_read;
>  .close=my_device_close;
>  .write=my_device_write;
>
>  }
> When the device driver is active then in
>
> /dev/mydevice
> you can actually read and write into it. But what I was not clear is
> how an application will read or write to this device. I know insmod
> will insert the module to kernel,and register_chrdev(); will register
> the driver in kernel but how will application program communicate with
> this driver.
>
>
> My answer was
> In unix it simply opens the device node as a file and sends/receives
> data and commands from it.
>
> But he was expecting some thing more complex.
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

Hi,

Not in touch with low level stuff for some time but do check ioctl() and
sysfs on wikipedia or man pages.

Take care.

-- 
Shahbaz Khan
R&D Engineer,
Tactical Engineering and Consultancy.

http://shazkhan.wordpress.com/
http://pk.linkedin.com/pub/shahbaz-khan/20/116/b49
http://imsciences.edu.pk/serg/
http://csrdu.org/
+92-91-332-9915828
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/66a69140/attachment.html