From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoann Padioleau To: "9fans@9fans.net" <9fans@9fans.net> Date: Sat, 18 Jan 2014 06:57:32 +0000 Message-ID: <725B0528-2ACD-49BF-B09C-8A0625C89080@fb.com> Content-Type: text/plain; charset="us-ascii" Content-ID: <824224DC673DFC449F35A13745BAE8C4@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [9fans] mechanism to bind partitions in /dev? Topicbox-Message-UUID: b3de40ec-ead8-11e9-9d60-3106f5b1d025 Hi, Can someone explain how the partitions in /dev/sdC0/xxx are populated? Who create those device files? I have a small plan9 kernel running a small shel= l (sh.Z) in memory and when I do 'bind #S/sdC0 /dev/' I just see the 'data', 'ctl',= and 'raw' files. There is no 9fat or plan9 or whatever partitions there is on this disk. In = fact I've tried to make on MACos via the Utility disk some fat images and when I do=20 qemu -hdb dosdisk.img I can not access again the fat partition on this disk (I've tried dossrv and then mount /srv/dos/ /mnt #sdC1/data but it does not= work). I can access it though when it's on a floppy disk (mount /srv/dos /mnt /dev= /fd0disk works). How fd0disk is different from #sdC1/data? From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <725B0528-2ACD-49BF-B09C-8A0625C89080@fb.com> References: <725B0528-2ACD-49BF-B09C-8A0625C89080@fb.com> Date: Sat, 18 Jan 2014 18:17:19 +1100 Message-ID: From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c38882f8847504f03972f1 Subject: Re: [9fans] mechanism to bind partitions in /dev? Topicbox-Message-UUID: b3e1e9c2-ead8-11e9-9d60-3106f5b1d025 --001a11c38882f8847504f03972f1 Content-Type: text/plain; charset=UTF-8 disk/prep (and it's mates) are what you need for sdC0. man 8 prep. brucee On 18 January 2014 17:57, Yoann Padioleau wrote: > Hi, > > Can someone explain how the partitions in /dev/sdC0/xxx are populated? Who > create those device files? I have a small plan9 kernel running a small > shell (sh.Z) > in memory and when I do 'bind #S/sdC0 /dev/' I just see the 'data', > 'ctl', and 'raw' files. > There is no 9fat or plan9 or whatever partitions there is on this disk. In > fact I've > tried to make on MACos via the Utility disk some fat images and when I do > qemu -hdb dosdisk.img I can not access again the fat partition on this disk > (I've tried dossrv and then mount /srv/dos/ /mnt #sdC1/data but it does > not work). > I can access it though when it's on a floppy disk (mount /srv/dos /mnt > /dev/fd0disk > works). How fd0disk is different from #sdC1/data? > > > > --001a11c38882f8847504f03972f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
disk/prep (and it's mates) are what you need for sdC0.= man 8 prep.

brucee


On 18 January 2014 17:57, Yoann Padiol= eau <p= ad@fb.com> wrote:
Hi,

Can someone explain how the partitions in /dev/sdC0/xxx are populated? Who<= br> create those device files? I have a small plan9 kernel running a small shel= l (sh.Z)
in memory and when I do =C2=A0'bind #S/sdC0 /dev/' I just see the &= #39;data', 'ctl', and 'raw' files.
There is no 9fat or plan9 or whatever partitions there is on this disk. In = fact I've
tried to make on MACos via the Utility disk some fat images and when I do qemu -hdb dosdisk.img I can not access again the fat partition on this disk=
(I've tried dossrv and then mount /srv/dos/ /mnt #sdC1/data but it does= not work).
I can access it though when it's on a floppy disk (mount /srv/dos /mnt = /dev/fd0disk
works). How fd0disk is different from #sdC1/data?




--001a11c38882f8847504f03972f1-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <725B0528-2ACD-49BF-B09C-8A0625C89080@fb.com> References: <725B0528-2ACD-49BF-B09C-8A0625C89080@fb.com> Date: Sat, 18 Jan 2014 11:33:40 -0800 Message-ID: From: Steven Stallion To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] mechanism to bind partitions in /dev? Topicbox-Message-UUID: b3e99672-ead8-11e9-9d60-3106f5b1d025 On Fri, Jan 17, 2014 at 10:57 PM, Yoann Padioleau wrote: > Hi, > > Can someone explain how the partitions in /dev/sdC0/xxx are populated? Who > create those device files? I have a small plan9 kernel running a small shell (sh.Z) > in memory and when I do 'bind #S/sdC0 /dev/' I just see the 'data', 'ctl', and 'raw' files. > There is no 9fat or plan9 or whatever partitions there is on this disk. In fact I've > tried to make on MACos via the Utility disk some fat images and when I do > qemu -hdb dosdisk.img I can not access again the fat partition on this disk > (I've tried dossrv and then mount /srv/dos/ /mnt #sdC1/data but it does not work). > I can access it though when it's on a floppy disk (mount /srv/dos /mnt /dev/fd0disk > works). How fd0disk is different from #sdC1/data? Hi Yoann, sdC0 and friends are populated by devsd (#S) as a part of some bootstrap goop. What you will typically find is that only the drive/partitions used to boot are populated, this is the reason for the readparts= plan9.ini variable. There are other ways to prompt devsd to create fs entries at boot - I'd suggest looking through /sys/src/9/port/devsd.c. Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoann Padioleau To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Sat, 18 Jan 2014 22:34:49 +0000 Message-ID: <0C50289C-23EE-40EB-BA61-360329772313@fb.com> References: <725B0528-2ACD-49BF-B09C-8A0625C89080@fb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="_000_0C50289C23EE40EBBA61360329772313fbcom_" MIME-Version: 1.0 Subject: Re: [9fans] mechanism to bind partitions in /dev? Topicbox-Message-UUID: b3ee0f22-ead8-11e9-9d60-3106f5b1d025 --_000_0C50289C23EE40EBBA61360329772313fbcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Got it, thx a lot. Just need to do fdisk -p /dev/sdC0/data > /dev/sdC0/ctl and then prep -p /dev/sdC0/plan9 > /dev/sdC0/ctl On Jan 17, 2014, at 11:17 PM, Bruce Ellis > wrote: disk/prep (and it's mates) are what you need for sdC0. man 8 prep. brucee On 18 January 2014 17:57, Yoann Padioleau > w= rote: Hi, Can someone explain how the partitions in /dev/sdC0/xxx are populated? Who create those device files? I have a small plan9 kernel running a small shel= l (sh.Z) in memory and when I do 'bind #S/sdC0 /dev/' I just see the 'data', 'ctl',= and 'raw' files. There is no 9fat or plan9 or whatever partitions there is on this disk. In = fact I've tried to make on MACos via the Utility disk some fat images and when I do qemu -hdb dosdisk.img I can not access again the fat partition on this disk (I've tried dossrv and then mount /srv/dos/ /mnt #sdC1/data but it does not= work). I can access it though when it's on a floppy disk (mount /srv/dos /mnt /dev= /fd0disk works). How fd0disk is different from #sdC1/data? --_000_0C50289C23EE40EBBA61360329772313fbcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <69BEDEB1661CF0409C11E152206FE826@fb.com> Content-Transfer-Encoding: quoted-printable Got it, thx a lot.
Just need to do  fdisk -p /dev/sdC0/data > /dev/sdC0/ctl
and then prep -p /dev/sdC0/plan9 > /dev/sdC0/ctl

 
On Jan 17, 2014, at 11:17 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:

disk/prep (and it's mates) are what you need for sdC0. man= 8 prep.

brucee


On 18 January 2014 17:57, Yoann Padioleau <pad@fb.com> wrote:
Hi,

Can someone explain how the partitions in /dev/sdC0/xxx are populated? Who<= br> create those device files? I have a small plan9 kernel running a small shel= l (sh.Z)
in memory and when I do  'bind #S/sdC0 /dev/' I just see the 'data', '= ctl', and 'raw' files.
There is no 9fat or plan9 or whatever partitions there is on this disk. In = fact I've
tried to make on MACos via the Utility disk some fat images and when I do qemu -hdb dosdisk.img I can not access again the fat partition on this disk=
(I've tried dossrv and then mount /srv/dos/ /mnt #sdC1/data but it does not= work).
I can access it though when it's on a floppy disk (mount /srv/dos /mnt /dev= /fd0disk
works). How fd0disk is different from #sdC1/data?





--_000_0C50289C23EE40EBBA61360329772313fbcom_--