9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Francisco J Ballesteros <nemo@lsub.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] installing on a usb disk
Date: Mon, 19 Jul 2010 15:52:12 +0200	[thread overview]
Message-ID: <AANLkTil8fs4BHulEN6Z8Dh968aZz65qV2zkuBSkRjgj3@mail.gmail.com> (raw)
In-Reply-To: <D6D9EE8E-97A1-4784-81B4-2994BB942186@corpus-callosum.com>

Ok. Then it's as expected.
In this usbdb, usb/disk is built into usbd.
That means that usbd will spawn a driver for disk as soon as it sees
a disk plugged in. If you run usb/disk on your own, there will be no unhandled
disks left for it and it should say that there are no disks and exit.

Regarding the mount, yes, the fs from usbd is to be mounted also at /dev
for usbfat and others to use. You might add an entry to your namespace file
if it's not mounted by default.

On Mon, Jul 19, 2010 at 3:48 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:
>
> On Jul 19, 2010, at 3:33 AM, Francisco J Ballesteros wrote:
>
>>>
>>> If I do:
>>>
>>>        usb/disk
>>>
>>> I get "no device found".  But if instead the command is:
>>>
>>>        usb/usbfat:
>>>
>>> I get /dev/sdU0.0 and /dev/sdU0.1 with plausible trees (ctl data raw).  The sdU0.0 corresponds to a usb/probe that returns:
>>>
>>
>> Are you running usbd with embedded disks? In that case the disks are owned by
>> the usb/disk linked into usbd, and the one you start by hand should
>> see no disks, as it happens.
>> I'd like to confirm this, just to know if it's a bug.
>
> That question made me go back to the man page and dig through the sources again.  It's the default/most recent configuration from yesterday's live CD.
>
>        cpu% cat usbdb
>        # only kb,  disk, and ether  are prepared for embedding.
>        # others are not yet converted to sit in the usbd device driver library
>        embed
>                kb      csp=0x010103 csp=0x020103       args=
>                disk    class=storage                   args=
>                ether   class=255 csp=0x00ffff          args=
>                serial  class=255 csp=0xffffff vid=0x9e88 did=0x9e8f    args=
>        #       wifi    class=0 csp=0 vid=0x0bda did=0x8192     args=
>        #       wifi    class=0 csp=0 vid=0x148f did=0x2870     args=
>
>
> Another side note: I had to explicitly do the following for anything to show up:
>
>        cat% mount /srv/usb /n/usb
>
>
>
>



      reply	other threads:[~2010-07-19 13:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-19  2:30 Jeff Sickel
2010-07-19  8:33 ` Francisco J Ballesteros
2010-07-19 13:48   ` Jeff Sickel
2010-07-19 13:52     ` Francisco J Ballesteros [this message]

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=AANLkTil8fs4BHulEN6Z8Dh968aZz65qV2zkuBSkRjgj3@mail.gmail.com \
    --to=nemo@lsub.org \
    --cc=9fans@9fans.net \
    /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).