Linux Hotplug development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Whitespaces in ID_VENDOR and ID_MODEL
Date: Mon, 05 Jan 2009 23:37:32 +0000	[thread overview]
Message-ID: <1231198652.4858.20.camel@californication> (raw)
In-Reply-To: <1231194390.4858.5.camel@californication>

Hi Kay,

> > so I was playing with adding environment variables to devices in the
> > udev database for later easy enumeration. And I like having ID_VENDOR
> > and ID_MODEL available and would like to extend this even to PCI and
> > SDIO in the future, but why are all whitespace replaced with "_".
> 
> > E: ID_VENDOR=Novatel_Wireless
> > E: ID_MODEL=Novatel_Wireless_HSUPA_Modem
> > E: ID_REVISION\000
> > E: ID_SERIAL=Novatel_Wireless_Novatel_Wireless_HSUPA_Modem_356846015115701
> 
> Yeah, all strings in usb_id are mangled to be used in symlink names.
> Like all the other *_id tools do too. When we started doing that,
> nobody thought we would ever use these strings for anything else than
> creating symlinks. :)

for things like ID_SERIAL this makes sense to me. For ID_VENDOR and
ID_MODEL not so much. Does udev itself use these values anywhere? Or can
we have udev just do the stripping part and have *_id tools return the
plain values?

> Some of the values, like ATA and SCSI just fill the whole remaining
> string buffer with whitespaces, which need to be stripped too, to be
> used in symlinks.
> 
> For stuff that needs to be reversible, like filesystem label strings,
> which can contain any char, need to be valid and safe chars to be a
> symlink, and we need to be able to translate the name back to the
> original value, we encode the string with url encoding, like:
>   ID_FS_LABEL=/
>   ID_FS_LABEL_ENC=\x2f
> 
> We need to sanitize the values at least for things like newline,
> quoting and other control chars, because most of these values are
> completely "untrusted userdata", and a fake device with a usb model
> string like "Foo\nBAR=1" we don't want to import unmangled. :)
> 
> If you have an idea what we should do/change to make these values more
> useful, let me know.

I agree that we need to do at least some kind of sanitization, but for a
lot of these values having the clear text strings available would be
really nice. Especially the ID_VENDOR and ID_MODEL strings. If udev is
having access to these string (like for USB or when creating unique
symlinks) anyway, then it makes no sense to not duplicate the logic to
these from the device.

Do you ever defined a character set for the environment values? It would
be nice if it UTF-8, because then we can copy most values natively.

Regards

Marcel



  parent reply	other threads:[~2009-01-05 23:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 22:26 Whitespaces in ID_VENDOR and ID_MODEL Marcel Holtmann
2009-01-05 22:59 ` Kay Sievers
2009-01-05 23:37 ` Marcel Holtmann [this message]
2009-01-06  0:24 ` Kay Sievers

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=1231198652.4858.20.camel@californication \
    --to=marcel@holtmann.org \
    --cc=linux-hotplug@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox