kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Sadanand Warrier <sadanandwarrier@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: Kernelnewbies@kernelnewbies.org
Subject: Re: syfs question
Date: Thu, 27 Feb 2020 09:41:21 -0500	[thread overview]
Message-ID: <CADJuq2w6qTitT5CRWZE+3ULhk0PmqCgJDrTYtyauEkZ0c63qNA@mail.gmail.com> (raw)
In-Reply-To: <20200226175445.GB273509@kroah.com>

On Wed, 26 Feb 2020 at 12:54, Greg KH <greg@kroah.com> wrote:

> > Using device_add I could populate the parent of the device and leave
> > the class empty or provide a class and get the device to be created in
> > the parent directory.
>
> I don't understand what you mean here.

Umm sorry was a bit dense there what I meant to say was that if the
device kobj was set up to point to the parent it would appear in that
parent's directory.
Additionally if the link to the parent was there and it also belonged
to a class it would
appear under the class directory in the parent hierarchy. Like so for
an ethernet interface
belonging to the class "net"  if I am in the sys directory.

-bash-4.2$ find . -name "eth*" -print
./class/net/eth1
./devices/pci0000:00/0000:00:02.2/0000:03:00.3/net/eth1


>
> > What exactly is the significance of the" /sys/devices/virtual"  directory?
> > Is this meant to carry devices of a specific type say something that is
> > divorced from actual hardware?
>
> Yes.  These are devices that do not have a "real" device backing them,
> they are "virtual" devices in that the kernel creates them usually
> because it needs a way for userspace to interact with the device.
>
> A good example of this are tty "devices".  They are attached to a "real"
> device in the system (pci, usb, platform, etc.) but the tty device
> itself is just there to provide the common interaction with userspace
> that userspace expects.

So would it be considered indecent to create a device under a parent directory
with a specific value of devno which we place in dev->devt value  and then
 create a character device with cdev_init/add and the same devno so
that the user
can access ioctl operations through the entry in /dev.
For e.g.
I create a device "xx" in
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/xx
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/xx/dev
243:0
and set up a character device xx like this using cdev_add/init
crw-------. 1 root root 243, 0 Jun 22 07:52 /dev/xx

In this case there is no device under /sys/devices/virtual but I could
open "/dev/xx" from user space and do ioctls etc. Of course I would be
limited to accessing sysfs attributes etc. through the real hardware device.
Is that frowned upon? Is a virtual device considered necessary for user space
 access?



> The uevent file is not written to (well, it can, but that does something
> different), it is read from to show what the attributes that are set
> when the uevent happens for that device.  It is populated by the
> bus or class for that device by a bus/class specific callback to that
> driver.
>
> Have you read the LDD3 chapter on the driver model for the kernel?  It's
> a bit out of date (well, really out of date), but the basics should
> still be semi-relevant and might answer some of your questions here.
>
> hope this helps,

Not in detail and I will do so but you have answered my question I
think. I'll check
the newer kernel code to see how the bus/class specific callback works.

Thanks

S

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2020-02-27 14:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 15:15 syfs question Sadanand Warrier
2020-02-26 17:54 ` Greg KH
2020-02-27 14:41   ` Sadanand Warrier [this message]
2020-02-28 12:37     ` Greg KH
2020-02-28 17:29       ` Sadanand Warrier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADJuq2w6qTitT5CRWZE+3ULhk0PmqCgJDrTYtyauEkZ0c63qNA@mail.gmail.com \
    --to=sadanandwarrier@gmail.com \
    --cc=Kernelnewbies@kernelnewbies.org \
    --cc=greg@kroah.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).