All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Sjur Brændeland" <sjurbren@gmail.com>
Cc: Amit Shah <amit.shah@redhat.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	virtualization@lists.linux-foundation.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [RFC] virtio_console: Add DRIVER and INTERFACE to uevent.
Date: Thu, 24 Jan 2013 08:51:39 -0800	[thread overview]
Message-ID: <20130124165139.GE15208@kroah.com> (raw)
In-Reply-To: <CAJK669Z6Mbs_igwV_KjLj8O-fOpD30J8uGbxN6OMk5qqxjVMpQ@mail.gmail.com>

On Thu, Jan 24, 2013 at 02:30:59PM +0100, Sjur Brændeland wrote:
> Hi Greg,
> 
> On Tue, Jan 22, 2013 at 5:16 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Tue, Jan 22, 2013 at 09:55:20AM +1030, Rusty Russell wrote:
> >> sjur.brandeland@stericsson.com writes:
> >>
> >> > From: Sjur Brændeland <sjur.brandeland@stericsson.com>
> >> >
> >> > Add information so rproc-serial can be easily recogniced
> >> > from user space. Add the following information to uevent:
> >> > DRIVER=virtio_console|virtio_rproc_serial
> >> > INTERFACE=grand-parent/parent/name
> >> >
> >> > Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
> >> > ---
> >> > Hi,
> >> >
> >> > I need some way to identify the major/minor number for
> >> > the rproc-serial device, given the udev event.
> >> > Review comments are welcomed.
> >> >
> >> > Thanks,
> >> > Sjur
> >>
> >> Hmm, I send all uevent questions to Greg KH (CC'd).
> >
> > The "INTERFACE" uevent variable is only for USB devices, so for anything
> > else to be sending userspace that variable, would confuse things
> > greatly.
> >
> > Sjur, what exactly are you trying to do here?  What do you want
> > userspace to know, and what should it do with that information?
> 
> I'm trying to help user-space make sense of the port-name generated
> by virtio_console. I'm using remoteproc and virtio_console for talking
> to a remote device (modem). At startup the port-device will be named
> vport<X>p0. If we get a reboot of the remote device, the device name
> will change to vport<Y>p0. It is difficult for applications to guess
> the X or Y values in order to get hold of the right file after a
> reboot.
> 
> If we at some point get more than one remote processor using
> virtio_console the port name may not even be deterministic.
> (X is currently just a monotonic counter).
> 
> The current device path is:
> /sys/devices/platform/ste-modem/remoteproc0/virtio0/virtio-ports/vport0p0
> 
> $cat uevent
> MAJOR=254
> MINOR=0
> DEVNAME=vport0p0
> 
> So what I'm trying to do is to add information to udev events in order
> to be able create good device names and be able identify the remoteproc
> device. I should probably also mention that we're currently running this on
> Android.

Ok, but why would you use the "INTERFACE" uevent field for something
like this?  All that looked to do was to export the path to your device,
which userspace already gets, right?

What were you thinking that you could send to userspace through a uevent
that would allow it to uniquely identify your device, that it already
doesn't have by just looking in the sysfs files for your device?

> The initial stab at this was to add information to the udev event.

Android doesn't use udev :)

> Another approach could perhaps be to change the way port-names are
> generated by virtio_console...

How would that help here?

The way to solve this is to provide userspace with some "unique"
identifier of your device.  Traditionally that is done with a number of
different methods:
	- serial numbers and other unique strings in sysfs files
	- device paths (plugged into the 3rd port on the 4th USB device)
	- a "label" in the device (think about filesystems)

All of these are either determined by sysfs files owned by the device
(and hence, no uevent changes are needed), or userspace can query the
device (filesystem labels).

Do you have anything that can help uniquely identify this device?  If
not, can you make something?

Hope this helps,

greg k-h

  reply	other threads:[~2013-01-24 16:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-17 12:23 [RFC] virtio_console: Add DRIVER and INTERFACE to uevent sjur.brandeland
2013-01-21 23:25 ` Rusty Russell
2013-01-22 16:16   ` Greg KH
2013-01-24 13:30     ` Sjur Brændeland
2013-01-24 16:51       ` Greg KH [this message]
2013-01-25  9:27         ` Amit Shah

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=20130124165139.GE15208@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=amit.shah@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=mst@redhat.com \
    --cc=sjurbren@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.