Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[Brian L. Stuart]

 I wouldn't call it obvious.  :)  It looks like there's at least a difference 
in where the firmware blobs are kept.  I don't really know how much difference 
there is in the driver code, but I would expect that there would be a file in 
/sys/src/9/bcm that is analogous to ether4330.c.  But I'll have to leave it to 
others who are more knoledgable about the 9front internals to follow up with 
more details.
In the absence of a more definitive direction, I'd grep the source files in 
/sys/src/9/bcm for the string 4345.  As a hex number, that is the chip ID for 
the 802.11 interface on the 4s.  The revision number on the original 4s was 6, 
but the revision on my 400 is 9.  In the 9legacy version that I use, the 
different IDs are listed in an array of structures:
struct {
    int chipid;
    int chiprev;
    char *fwfile;
    char *cfgfile;
    char *regufile;
} firmware[] = {
    { 0x4330, 3,    "fw_bcm40183b1.bin", config40183, 0 },
    { 0x4330, 4,    "fw_bcm40183b2.bin", config40183, 0 },
    { 43362, 0,    "fw_bcm40181a0.bin", config40181, 0 },
    { 43362, 1,    "fw_bcm40181a2.bin", config40181, 0 },
    { 43430, 1,    "brcmfmac43430-sdio.bin", "brcmfmac43430-sdio.txt", 0 },
    { 43430, 2,    "brcmfmac43436-sdio.bin", "brcmfmac43436-sdio.txt",  
"brcmfmac43436-sdio.clm_blob" },
    { 0x4345, 6, "brcmfmac43455-sdio.bin", "brcmfmac43455-sdio.txt", 
"brcmfmac43455-sdio.clm_blob" },
    { 0x4345, 9, "brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", 
"brcmfmac43456-sdio.clm_blob" },
};

The code then runs through the array comparing the ID and rev read from the 
controller.  When it finds a match, it sends over the various blobs.  The code 
that looks for the blobs in the 9legacy driver is:

    if(!waserror()){
        snprint(nbuf, sizeof nbuf, "/boot/%s", file);
        c = namec(nbuf, Aopen, OREAD, 0);
        poperror();
    }else if(!waserror()){
        snprint(nbuf, sizeof nbuf, "/sys/lib/firmware/%s", file);
        c = namec(nbuf, Aopen, OREAD, 0);
        poperror();

If it's the same in 9front, then the blobs you have might be /boot which would 
be necessary if you were going to take the root from a file server over wifi.  
I don't ever run mine that way, so it's more convenient for me to put them in 
/sys/lib/firmware.
As before, I'll need to leave it to a 9front expert to point out any of my 
suppositions that are wrong.

Sorry for the delay.  I took a couple of hours out to take advantage of a break 
in the clouds here to test my setup for the eclipse on Monday.  And btw, the 
computer I'll have there will be my 400 running Plan 9 with the file system 
I'll be talking about at IWP9 next weekend.

BLS


On Saturday, April 6, 2024 at 07:15:16 AM UTC, taylor.ga...@gmail.com 
 wrote:  
 
 Hi Brian, 
Thanks for your help, does it make a difference that I'm using 9front? I don't 
even seem to have a /sys/lib/firmware directory, and I'm not sure I have a 
ether4330.c either. 

I'm sure it's obvious, but I'm a newcomer to Plan 9 and I apologise in advance 
if I'm missing obvious things.

Thanks

Garry9fans / 9fans / seediscussions +participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M21bff740cfc3be6ecf936bdb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[Brian L. Stuart]

 I haven't had any trouble with wifi on the 4, with one caveat.  The 400 (and 
maybe some of the later 4s) have an updated version of the radio.  It just 
takes a new entry in ether4330.c and new blobs in /sys/lib/firmware.  The entry 
I've got in my ether4330.c is:
    { 0x4345, 9, "brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", 
"brcmfmac43456-sdio.clm_blob" },

and the files named there are the ones I added to /sys/lib/firmware.
BLS


On Saturday, April 6, 2024 at 01:33:46 AM UTC,  
wrote:  
 
 That's great, now I just need to get wifi to work... I can't get a definitive 
answer on RPi 4 wifi is even supported.9fans / 9fans / seediscussions 
+participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M5332574c9fdef8908ac6b551
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] IWP9 Update

[Brian L. Stuart]

Some of you may have noticed that the original deadline for the 
camera-readycopy of papers and the WiP reports is today.  The committee has 
decidedto extend that deadline by one week.  So anyone for whom the edits 
haveslid to the back burner, you've got a reprieve.  After the new deadline 
onthe 20th, we'll work on putting the online proceedings together.
Thanks,BLS

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6f56828c4f9d22bd-Mfea55b6d44f429aff88ba6b0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] IWP9 Hotels

[Brian L. Stuart]

A week ago I sent out a request for interest in a hotel room block at 
$200/night.  I got exactly one response saying that's what AirBNB is for.  
Unless I hear differently by sometime tomorrow, I'll interpret the lack of 
response as indicating that everyone has or is planning to make their own 
arrangements and that I should tell them to cancel the request and release the 
rooms.

Thanks,
BLS

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdb8ab372e27e1518-M4a796a93e9171e0a318c24e6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] IWP9 Housing

[Brian L. Stuart]

The housing situation for IWP9 this year in Philadelphia is not
ideal. It seems there's a big volleyball tournament in town at the
same time, so many hotels have little availability and they're
able to charge high rates. However, we have had one that has said
they can reserve a block of rooms for us at $200/night. That is
the Club Quarters hotel. While it's not super close to campus,
it's close enough to the subway that you won't need to plan on
lots of Uber. As is commonly the case, we'll have to guarantee at
least 80% of the number of rooms we have them reserve to be
occupied. We also need to get the block reserved pretty soon as I
don't know how long they'll be able to hold some openings for us.

So I'd like to get a headcount of how many rooms we're likely to
use. Send me a reply and let me know if you are likely to reserve
a room in the block at Club Quarters at the $200 rate.

Thanks,
BLS


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1e48f24607670833-M8fbb2ba70c0e032152275f60
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] IWP9 10th Edition

[Brian L. Stuart]

The Plan 9 Foundation and the Workshop Program Committee are
pleased to invite participation in the 10th International
Workshop on Plan 9.  This event will take place April 12-14,
2024 on the campus of Drexel University in Philadelphia.  We
invite submission of papers, works in progress (WiPs), and
workshop proposals.  Everyone interested in Plan 9 and
related technologies is encouraged to attend.

To assist in your planning, a few key dates include:
January 30, 2024: Submission Deadline
March 10, 2024: Preferred Registration Deadline (later
registrations will be accepted)
April 12-14, 2024: The Workshop
We will be following up with details on hotels.

For complete details, see the Call for Papers at:

https://www.cs.drexel.edu/~bls96/iwp9_2024_cfp.pdf

A special note on scheduling: the workshop falls on the
weekend following the upcoming total solar eclipse on April
8, 2024. Although we will not have totality in Philadelphia,
the path of totality is reachable from Philadelphia in less
than a day's driving time. So take advantage of the
scheduling to experience both one of nature's most amazing
events and discussions of computing's most amazing operating
system.

Brian L. Stuart
IWP9 Program Committee

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfe83e4e703ab52ec-M6f703d0608c259fe194a198d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Fun with sshsession

[Brian L. Stuart]

On Thu, Dec 08, 2022 at 06:06:21PM -0600, Steven Stallion wrote:
> > I found another interesting wrinkle.  It appears this issue seems to
> > only affect diskless CPU servers.  I'm able to SSH successfully to my
> > auth and file servers.
> 
> Mystery solved!  It turns out this was the same issue Cinap fixed in
> auth/as last year.  sshsession was inheriting the host owner factotum
> after capuse, which was leading to breakage on hosts other than the
> file server.

Steve,
I'm glad to hear you got it sorted out.  Now that our fall term is
over, I can come up for air.  But I didn't have much to add to
your search anyway.

About the only thing I've done with it since Geoff's clean-up
was recently adding some new key exchange algorithms since
OpenSSH no longer supports the original required KEX algorithms
out of the box.  The server side of things was always a little
goofy.  It does carry the fingerprints of being developed to
allow customers to ssh into appliances that didn't share an
auth server.  I never got around to doing much aimed at making
it natural for non-Plan 9 clients to log into a full Plan 9
environment with ssh.  There never seemed to be a lot of motivation
because drawterm seemed to provide a better interface.  The
main exception would be using sam -r from a non-Plan 9 system.

In the end, it ended up being a perfect example of an implementation
influenced by lots of "here's something cool that could be done
with it" ideas.  But then pretty much none of the cool capabilities
ever got used.  I do still use the client functionality a lot
from a Pi 400 running a slightly enhanced copy of Richard's
Pi image in the classroom talking to my BSD laptop and the
department's Linux cluster.

Not that any of that is relevant to the issue you ran into, but
it might help provide a little context to anyone wondering how
and why that implementation works the way it does.

BLS



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta343100f1654631e-Md53baf982ecb1d9255d61ee1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Raspberry Pi400 Ethernet

[Brian L. Stuart]

On Friday, May 28, 2021, 3:12:26 PM EDT, Steve Simon  
wrote: 
> sadly i have had problems with usb3 which is on
> my todo list - usb2 devices work fine as do usb3
> devices in usb2 sockets.

I'll definitely keep that in mind.  I haven't been
trying to use any USB3 devices, but who know
what'll happen.

BLS

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M3246d8de0bd9d31f1c12bbac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Raspberry Pi400 Ethernet

[Brian L. Stuart]

I'll check on that.  Though in this case, I was booting
from the SD card and then running ipconfig by hand
to get an address.

BLS







On Friday, May 28, 2021, 4:11:04 PM EDT, Skip Tavakkolian 
 wrote: 





might be this (from the diffs gist i posted earlier):
    case ODtftpserver: /* RPi4s request it for no-SD netbooting
without hardcoding TFTP_IP in EEPROM */

On Fri, May 28, 2021 at 12:13 PM Brian L. Stuart  wrote:
>
> On Friday, May 28, 2021, 2:52:35 PM EDT, Richard Miller <9f...@hamnavoe.com> 
> wrote:
> >> The really odd part is I just moved the SD card over
> >> from a pi3 that was booting fine with dhcp.
> >
> > Does the MAC address in the dhcp request look right?
> 
> It does.  I'm at a loss to explain it, but I ended up rebooting
> my auth/dhcp server and now everything is working.
> 
> False alarm, I guess.
> 
> Thanks,
> BLS



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M59de3a6995dc4de76608d14f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Raspberry Pi400 Ethernet

[Brian L. Stuart]

On Friday, May 28, 2021, 2:52:35 PM EDT, Richard Miller <9f...@hamnavoe.com> 
wrote: 
>> The really odd part is I just moved the SD card over
>> from a pi3 that was booting fine with dhcp.
>
> Does the MAC address in the dhcp request look right?

It does.  I'm at a loss to explain it, but I ended up rebooting
my auth/dhcp server and now everything is working.

False alarm, I guess.

Thanks,
BLS

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M0975e43cb2c172ae2a9dc63c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Raspberry Pi400 Ethernet

[Brian L. Stuart]

I'm inclined to think you're on the right track with
a dhcp problem.  It seems to be working fine if I
set the address manually on the command line.
The really odd part is I just moved the SD card over
from a pi3 that was booting fine with dhcp.  I'll keep
digging.

BLS







On Friday, May 28, 2021, 2:28:16 PM EDT, Richard Miller <9f...@hamnavoe.com> 
wrote: 





I have no personal experience of the pi400 but I believe the ethernet
hardware is identical to the pi4. Could it be a configuration problem?
Can you run snoopy or equivalent on the network segment and see if the
dhcp requests are being transmitted? And check the dhcp server log to
see if there's a reason for non-response? Also you can try using
ipconfig to set a specific ip address and gateway without using
dhcp, to see if it's a dhcp problem or a more fundamental ethernet problem.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M9351afac61fe9f7850128c94
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Raspberry Pi400 Ethernet

[Brian L. Stuart]

So I picked up a pi400 and everything seems happy
except the Ethernet.  I'm using Richard's latest 9pi.img
from 9p.io.  At least, I'm pretty sure it's the latest; it
does include the /dev/serial driver.  The network switch
is showing the hardware to be happy and I'm using a
cable that has been working with a Pi3, but ipconf
times out with a "no success with DHCP" error.  Anyone
have any wisdom that I'm overlooking?

Also, Richard, I'm going to send you a bug fix for devspi
soon.  I discovered that attempting to acces spictl is
broken.

BLS

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M1cdfe9038b2b15321b2eff4d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Jim McKie

[Brian L. Stuart]

 I never got to know Jim, but I always respected his
contributions. He will be sorely missed.

RIP


 On Wednesday, June 24, 2020, 08:37:21 PM EDT, Charles Forsyth 
 wrote:  
 
 I am sorry to say that Jim McKie (jmk) died suddenly on 16 June. 
https://www.ippolitofuneralhomes.com/obituaries/James-B-McKie?obId=15111702=IwAR3d7aHZXEOhYz-ciOrQPh-W1eMw-_8MHiCUdeKOxzLBEI6VGHsSn4aTjdk9fans
 / 9fans / seediscussions +participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td73b359f9dc68c15-Mbcf37e5c21c11335f5777929
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 on virtual machine in Mac os

[Brian L. Stuart]

 On Wednesday, March 25, 2020, 02:02:40 PM EDT, Ethan Gardener 
 wrote:
> i still miss 9vx. it was so convenient when it
> worked. fun too; i had it full-screened in a little
> ...

Was? I still use it everyday. It's my primary
terminal. I have it take the root from my file
server when I'm on my home network, and
off a little local mini root when I'm not.

BLS

  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta7f245368d4d10b8-M0e5d29d3ab8739b0823f305b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Raspberry Pi 2 GPIO

[Brian L. Stuart]

 On Thursday, September 12, 2019, 5:43:13 AM EDT, Richard Miller 
<9f...@hamnavoe.com> wrote:
> > Do you also need the man pages for i2c and
> > spi, or did I send those the first time around?
>
> If you sent them, they must have gone astray ... if you can
> supply a new copy, I'll add them to the image too. Thanks!

Okay. I've appened at the end here both of them, i2c
first. I think they're up to date, but it's been a while since
I did much with them, and I can't vouch for how well my
memory works as the years go by.

BLS

.TH I2C 3
.SH NAME
i2c \- basic I2C interface
.SH SYNOPSIS
.B bind -a
.BI #J n
.B /dev
.PP
.BI /dev/i2c. n .ctl
. br
.BI /dev/i2c. n .data
.fi
.SH DESCRIPTION
.I I2c
serves a one-level directory with two files
that give access to the target device with address
.I n
(given in hexadecimal)
on the system's I2C bus.
.I N
is usually determined by the I2C device manufacturer.
I2C gives address 0 special meaning as the `general call' address.
See an I2C specification for details.
.PP
The control file
.BI i2c. n .ctl
accepts commands to set the valid address range and
subaddressing mode for the corresponding data file.
The following control messages can be written to it:
.TP
.B a10
Force 10-bit addressing instead of 7-bit addressing.
Otherwise 10-bit addressing is used only if the device address
.I n
is bigger than 255.
.TP
.BI size " nbytes"
.br
Set the logical size of the target device to
.IR nbytes .
(By default when opened, it is 256 bytes, enough for most small I2C devices.)
IO requests will be kept within this limit.
This value is also returned by
.B Sys->stat
as the length of the data file.
.TP
.BI subaddress " \fR[\fP n \fR]\fP"
.br
Cause subsequent reads and writes
on the data file to use I2C subaddressing
with
.I n
byte subaddresses (default: 1 byte).
.I N
must be no larger than 4.
The target device must support subaddressing.
By default, the device is not subaddressed.
Setting
.I n
to zero switches off subaddressing.
.PP
When read,
the control file displays the current settings.
.PP
The data file
.BI i2c. n .data
can be read or written to
exchange data with the slave device with address
.I n
(where
.I n
is given in hexadecimal).
Each write request transmits the given data
to the device.
Each read request sends a receive
request to the device and returns the resulting data.
If the I2C target is subaddressed, the current file offset
is used as the subaddress;
otherwise the file offset is ignored, and the device typically starts at 0 for 
each transfer request.
Read and write requests are trimmed to the declared
size of the device.
.SH SOURCE
.B /sys/src/9/bcm/devi2c.c
.br
.B /sys/src/9/bcm/i2c.c

.TH SPI 3
.SH NAME
spi \- access to the main Raspberry Pi SPI interface
.SH SYNOPSIS
.B bind -a #π /dev
.PP
.B /dev/spictl
.br
.B /dev/spi0
.br
.B /dev/spi1
.SH DESCRIPTION
The Broadcom SoC on the Raspberry Pi has three SPI interfaces:
the main SPI interface, designated SPI0, and two auxiliary SPI
interfaces, designated SPI1 and SPI2.
On the first generation Pis, only SPI0 was brought out to the
header on the board.
For the B+ and Pi2 models, SPI0 and SPI1 are available.
The driver described in this man page only supports SPI0.
.PP
Reads and writes to the files
.B spi0
and
.B spi1
transfer data over the SPI bus.
Accesses to
.B spi0
cause the transfers to take place with the CE0\_0 line asserted
low.
Similarly, transfers to
.B spi1
are carried out with CE1\_0 asserted low.
.PP
The
.B spictl
file is used to set various control parameters.
It accepts the following commands:
.TP
.BI clock " freq"
Set the frequency of the SPI clock.
The clock from which the SPI clock is derived runs at 250MHz,
and the Broadcom documentation specifies that the divisor
must be a power of 2.
The driver sets the divisor to the highest power of 2 that results
in a clock rate that is less than or equal to the
.I freq
parameter in MHz.
.TP
.BI mode " n"
Treats
.I n
as a two-bit number specifying the settings for the clock phase
and clock polarity.
The default value of 0 matches the polarity and phase requirements
of most peripheral devices.
.TP
.B lossi
Enable a bidirectional mode where the MOSI line is used for both
reads and writes.
.SH SOURCE
.B /sys/src/9/bcm/devspi.c
.br
.B /sys/src/9/bcm/spi.c
.SH BUGS
The various SPI modes are untested and the LoSSI support is
unimplemented.

  

Re: [9fans] Raspberry Pi 2 GPIO

[Brian L. Stuart]

 On Tuesday, September 10, 2019, 12:21:32 PM EDT, Richard Miller 
<9f...@hamnavoe.com> wrote:
> Thanks Brian, I'll add your man page to the 9pi image for the
> next update.

You're welcome. Do you also need the man pages for i2c and
spi, or did I send those the first time around?

Thanks,
BLS
  

Re: [9fans] Raspberry Pi 2 GPIO

[Brian L. Stuart]

 On Tuesday, September 10, 2019, 10:27:08 AM EDT, Олег Бахарев 
 wrote:
> Need man page for this.

My bad. I thought I had sent man pages along with the
code. I've included the man page for it at the bottom of
this message.

> Can you get some example for reading/writing GPIO ?

I've also included a short example that uses both
the GPIO and the SPI interface to talk to a little
Nokia LCD screen.

BLS

.TH GPIO 3
.SH NAME
gpio \- access to Raspberry Pi GPIO pins
.SH SYNOPSIS
.B bind -a #G /dev
.PP
.B /dev/gpio
.fi
.SH DESCRIPTION
.I Gpio
serves a single file that provides access to the GPIO pins on the
Raspberry Pi.
Reads from the file receive a 16-character hexadecimal string
representing a
.B vlong
giving the values of up to 64 GPIO lines.
(The processor on both the first and second generation Pis provides
54 actual GPIO lines.)
The proper method for sampling GPIO 27 is as follows:
.IP
.B read(gfd, buf, 16);
.br
.B buf[16] = 0;
.br
.B gvals = strtoull(buf, nil, 16);
.br
.B "pin27 = gvals & (1 << 27);"
.PP
Writes to
.B gpio
control the characteristics and output values of GPIO lines.
The exact operation is specified by one of the following commands:
.TP
.BI function " pin f"
Set the function of GPIO
.I pin
to
.I f.
The valid values for
.I f
are:
.BR in ,
.BR out ,
.BR alt0 ,
.BR alt1 ,
.BR alt2 ,
.BR alt3 ,
.BR alt4 ,
.BR atl5 ,
and
.BR pulse .
The functions
.B in
and
.B out
set the specified GPIO line to be a general purpose input
and output, respectively.
The various
.BI alt n
functions are as specified in the Broadcom documentation and
differ on a per-pin basis.
The
.B pulse
function is somewhat specialized.
It causes the pin to be set to an output for
2μS and then to be set to a input.
With the value of the line set to 0 and a pullup resistor on the
line, this operation provides a short low pulse suitable for bit-banging
a 1-wire interface.
.TP
.BI pullup " pin"
Enables the internal pullup resistor for the specified GPIO pin.
.TP
.BI pulldown " pin"
Enables the internal pulldown resistor for the specified GPIO pin.
.TP
.BI float " pin"
Disables both internal pullup and pulldown resistors for the specified
GPIO pin.
.TP
.BI set " pin value"
For GPIO pins set to the output function, this command sets the output
value for the pin.
The
.I value
should be either 0 or 1.
.SH NOTES
All pin number references are according to the SoC documentation.
These GPIO signal numbers do
.I not
match the pin numbers on the header on the Pi board.
Reads sample the external signal values.
As a result, the values read for output pins might not match
the value written to them if externally they are driven harder
than the SoC drives them.
.SH SOURCE
.B /sys/src/9/bcm/devgpio.c
.br
.B /sys/src/9/bcm/gpio.c


#include 
#include 

void
main()
{
 int gfd, sfd, i, j;
 uchar buf[256];

 gfd = open("/dev/gpio", ORDWR);
 sfd = open("/dev/spi0", ORDWR);
 if(gfd < 0 || sfd < 0)
 print("open error: %r\n");

 fprint(gfd, "function 22 out");
 fprint(gfd, "set 22 0");
 sleep(1);
 fprint(gfd, "set 22 1");
 fprint(gfd, "function 27 out");

 fprint(gfd, "function 26 out");
 fprint(gfd, "set 26 1");
 sleep(10);
 fprint(gfd, "set 26 0");
 fprint(gfd, "set 27 0");
 sleep(1);
 buf[0] = 0x21;
 pwrite(sfd, buf, 1, 0);
 sleep(1);
 buf[0] = 0x14;
 pwrite(sfd, buf, 1, 0);
 sleep(1);
 buf[0] = 0xc0;
 pwrite(sfd, buf, 1, 0);
 sleep(1);
 buf[0] = 0x20;
 if(pwrite(sfd, buf, 1, 0) < 0)
 print("write error: %r\n");
 sleep(1);
 buf[1] = 0x0c;
 if(pwrite(sfd, buf+1, 1, 0) < 0)
 print("write error: %r\n");
 sleep(1);
 buf[2] = 0x40;
 if(pwrite(sfd, buf+2, 1, 0) < 0)
 print("write error: %r\n");
 sleep(1);
 buf[3] = 0x80;
 if(pwrite(sfd, buf+3, 1, 0) < 0)
 print("write error: %r\n");
// pwrite(sfd, buf, 4, 0);

 fprint(gfd, "set 27 1");
 for(j = 0; j < 256; ++j) {
 for(i = 0; i < 16; ++i)
 buf[i] = j ^ i;
 sleep(1);
 for(i = 0; i < 6 * 84 / 16; ++i)
 pwrite(sfd, buf, 16, 0);
 sleep(100);
 }
 fprint(gfd, "set 26 1");
}
  

Re: [9fans] Are there disadvantages to walk?

[Brian L. Stuart]

On Mon, 4/1/19, Ethan Gardener  wrote:
> I remember hearing of some disadvantage to
> walking directories, but can't remember what it was. 
> Could someone remind me, please?  Perhaps there was
> more than one, of course.  Perhaps a performance trick
> couldn't be employed?
 
The only complaint I've had about walk was the expectation
in the protocol that servers produce the list of Qids all
the way down.  That got in the way when experimenting
with a server that used a hash table of full path names
to speed the walk process.

BLS

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

[Brian L. Stuart]

On Tue, 10/30/18, Richard Miller <9f...@hamnavoe.com> wrote:
> > Is there a technical reason (beside fonts that do not cover them) not
> > to use a Unicode values for the first letter?
> 
> They're a bit harder to produce on the keyboard.
 
Especially if you're at a VT-220 on the console and can't
run rio.

Don't laugh.  I actually have a VT-220 on my file server.

BLS

Re: [9fans] what heavy negativity!

[Brian L. Stuart]

Fri, Oct 5, 2018 at 12:11 AM Mayuresh Kathe  wrote:
> man, i experienced such heavy negativity towards my efforts to build ...
>
> the idea was to have a 64-bit linux kernel with the advantages of
> plan9port (small and elegantly designed+developed tools).

Mayuresh,
To echo what others have said, don't let the negativity
itself affect your work.  Consider only the technical points
that have been raised.  To the extent that you evaluate
them and consider them relevant to your objectives, factor
them into your work.

It really doesn't matter if anyone else ever cares about
or uses your work.  If you learn from it, get intellectual
satisfaction from it, and it's useful to you, then it's worth
doing.  If others can benefit too, great, but lack of interest
on the part of others is not a good reason for lack of
initiative on your part.  As far as I can tell, I'm the only
one using a file system I developed.  Sure, in some ways
I would like if everyone thought it was as great as I do,
but just because they don't doesn't stop me from benefitting
from it.

As for the specifics of your project, I personally don't think
I'd be all that interested in the results.  As much as I like
the elegance and simplicty of the implementation of the
Plan 9 user-land, much of the beauty of the system comes
from the simplicity and elegance of the kernel.  So if I
were using the Plan 9 user-land on top of the LInux kernel,
I wouldn't feel the same sense of beauty, intellectual satisfaction,
and connection to the original developers as I do running
the same user-land on the Plan 9 kernel.  But just because
I wouldn't be interested is no reason to stop your research.
Just be sure to study the similar efforts that have come
before and that have been mentioned here.  What did
they accomplish?  Did they go wrong somewhere?  Can
you get to that goal avoiding those mistakes?  If nothing
else, the whole experience will almost certainly give you
a greater appreciation for the Plan 9 kernel.

Just a couple of thoughts from an old-timer who misses
the days of working on PDP-11s.

BLS

Re: [9fans] 9P or better file services for multiple platforms

[Brian L. Stuart]

On Sat, 9/1/18, Lucio De Re  wrote:
> I'm trying to arrive at the most elegant solution to the following
> problem that does not sacrifice a great deal of efficiency. And, maybe
> I need to state this, the final result must be as robust or more
> robust than what I have in place currently, which has yet to let me
> 
> My system mixes up Plan 9 and Linux platforms, none of them
> 
> My hope is to provide a central file server that fulfills reliable
> file services to both Plan 9 and Linux as seamlessly as possible. I am

I'm not going to make any guarantees about the reliability,
but I do have a file system running on Plan 9, that natively
provides NFS service as well as 9P.  I also run it with a
snapshot device under it and get the type of history we
expect in a Plan 9 world.  To make the *nix side happy,
it does support symbolic links.  (Reading a symlink in Plan 9
just results in the path name string that the link points to.)
And to make things really fun, it also serves AOE.

I've been running it now on my home system for several
years.  I honestly don't use the NFS capability all that often,
but I did test it a fair amount back at Coraid.  Recently, I
added a little feature to the snapshot device to allow me
to easily migrate to a larger disk.  As a matter of fact, I read
your e-mail in acme on a 9vx which was taking its root from
this file system.

I'm sure there are plenty of nits that people could pick with
it and the details of its design, but it was an interesting
approach to experiment with and it's been serving me
well for about 4 or 5 years.  The file system itself runs in
user space on vanilla Plan 9, and the snapshot device
can be added to the kernel very easily.

Although there is a version of both the snapshot device
and the file system on contrib, if anyone's interested, I
can get you the most recent code to play with.

BLS

Re: [9fans] What are you using Plan 9 for?

[Brian L. Stuart]

On Wed, 6/20/18, Ethan A. Gardener  wrote:
> but on the back burner is a
> Forth-based project; a sort of operating system where the
> primary interface to all tasks is a Forth interpreter. So
> far, I've written the basics of a text editor. It's
> *very* little code!

I love seeing this idea coming back around.  Way back
in college, one of my senior projects was a little OS on
the PDP-11 that was done exactly this way.  The app
language and the command language were a Forth
implementation I had done out of curiosity in my freshman
year.  About a year and half ago, I got it running again,
first in simh, then on a little LSI-11 in those cute little
BA11-VA boxes.  It was wild seeing that running again
after over 30 years, and I found and fixed a concurrency
bug. :)  One of my students did (mostly just started on)
a project his past term that's gotten me to thinking a
little about reimplementing the whole thing on a Pi.

BLS

Re: [9fans] What are you using Plan 9 for?

[Brian L. Stuart]

On Fri, 6/15/18, Mark van Atten  wrote:
> On Fri, Jun 15, 2018 at 6:44 PM, Brian L. Stuart  
> wrote:
> > Can't say for LInux, but I run it all the time under 64-bit FreeBSD.
> 
> As of 11.0, FreeBSD has its own fdclose() with conflicting types.
> https://github.com/0intro/vx32/issues/3
> 
> Did you patch it, or are you running an earlier FreeBSD?

As I recall, I'm still running a binary I built on FreeBSD 10.  It
looks like it's dated Jun 2016.  So I hadn't noticed the conflict.

BLS

[9fans] Plan9 on Pi 3B+

[Brian L. Stuart]

Has anyone tried Plan 9 on the new Pi 3B+?  I've
run into something that confuses me a bit.  First,
it seems you need the new version of start_cd.elf
to bring up the 3B+.  However, with that, the kernel
throws a lock loop error.  In tracking down the loop,
it happens in startcpus() in archbcm2.c.  The code
here looks like:

for(i = 0; i < ncpu; i++)
lock([i]);
cachedwbse(startlock, sizeof startlock);
for(i = 1; i < ncpu; i++) {
if(startcpu(i) < 0)
return i;
lock([i]);
unlock([i]);
}

So we grab a lock on all the CPUs, then drop into
a second loop where we start CPUs 1 to n.  But
in that loop we grab the lock again and then
immediately unlock it.  This is where the lock
loop happens.  Everything seems to continue
to be happy on both a 2 and a 3B+ if I comment
out the lock in the second loop.  But what is the
rationale for the lock in the second loop?  Was
there a reason for putting it there, or was it an
oversight that wasn't exposed until the new boot
code?

Thanks,
BLS

Re: [9fans] Inferno on Plan9

[Brian L. Stuart]

Alexander Kapshuk wrote:
> On Thu, Dec 28, 2017 at 9:54 PM, Brian L. Stuart <blstu...@bellsouth.net> 
> wrote:
>> Which version of FreeBSD did you use, and did you use the
>> Inferno on bitbucket?  I'm finding it a long way from building
>> out of the box there these days.
> 
> While not a FreeBSD user, the bitbucket repository is:
> grep bitbucket ~/inferno-os/.hg/hgrc
> default = https://bitbucket.org/inferno-os/inferno-os
> 
> Care to elaborate a bit more on what sort of trouble you're having
> building Inferno on your system?
 
I'm using FreeBSD 11.1.  Things have changed a little since
they switched from gcc to clang.  I'm also running on an am64
install.

First, I had to rebuild mk.  The supplied binary expected the
libc shared library to be named libc.6.so, but the one present
on the system is just libc.so.  In doing that, I found there was
no setfcr-FreeBSD-386 source file.  Copying the Linux one
made it possible to build lib9.  Now I'm fighting with the floating
point stuff.  None of the FP constants are found.  I seem
to remember running into the same thing last year and did
eventually sort it out.  The other problem then was that a
couple of the X libraries weren't part of the 32-bit support
and I could only build emu-g.

BLS

Re: [9fans] Inferno on microcontrollers

[Brian L. Stuart]

On Sun, 12/31/17, Bakul Shah  wrote:

> I don't think we can assume a more popular plan9 would have
> met the fate of Linux. What bothers (some of) us is not that
> Linux is mainstream but that it is far too complicated and
> kitchensinky.

I'd like to think that there can be widespread use without the
bloat and absurdities.  However, I suspect that overly complicated
and kitchensinky is necessary for mainstream.  From what I've
observed over the last 40 years, even among those who are
technically educated, the subset who will choose well-designed
over packed-with-unused-features is sadly small.  Seeing how
many "modern" programmers immediately reach for the obscene
JavaScript "frameworks" for everything they do is enough to
drive one to drink.

I will admit that the cause and effect might also work in the other
direction.  There does seem to be a very real case to be made
that as a system becomes more popular, it attracts more people
who lack the judgement and the good taste to say 'no' to features
that don't fit well.

Personally, I think that popularity and bloat form a positive
feedback loop that stalls out once the complexity budget is
exhausted.  From then on, all future releases merely rearrange
the bugs.  Certainly, I'd love to be proved wrong.  But I can't
think of any examples where the mainstream user and developer
communities were able to resist the latest "ooh shiny."  Just
look how long it's taken for the community to realize that flash
was a bad idea.

BLS

Re: [9fans] Inferno on Plan9

[Brian L. Stuart]

On Sat, 12/30/17, Andre Wingor  wrote:
> And also ready-made live distributions for launching from USB and
> installing on a desktop with simple copying
> without admins privileges.
 
I haven't thought about anything along those lines with the
hosted versions, but a while back I did start putting together
a bootable live CD running natively.  Graphics were limited
to standard VGA (640x480x16 IIRC) and I ran out of momentum
when messing around with Ethernet drivers on older laptops.

For a hosted version, as long as you only targeted various
Unices, you could probably have a shell script that figured
out which emu to run based on the output of uname.

BLS

Re: [9fans] Inferno on microcontrollers

[Brian L. Stuart]

On Sun, 12/31/17, Rui Carmo  wrote:
> I honestly don’t think Plan9 or Inferno will become
> “general use” without (at the very least) a modern
> browser,

For which we can all be grateful.  "General use" is not a
good thing to be desired.  One of the biggest reasons I
moved away from Linux was that it was becoming too
mainstream for me.

> Inferno, dis and 9p seem like a good fit for
> embedded devices,

Very true.

> So I’d like to know if anyone here knows about
> recent efforts to run Inferno on other tiny
> machines...

Not particularly recent, but several years ago I ported
Inferno to the SunSPOT device.  As I recall, the version
I was using had 1MB of RAM and 4MB of flash.  It took
some squeezing (like severely reducing the size of the
ARP tables), but I did get it running including IPv6 over
the 802.15.4 radio in it.

BLS

Re: [9fans] Inferno on Plan9

[Brian L. Stuart]

On Fri, 12/29/17, Bakul Shah <ba...@bitblocks.com> wrote:
> On Fri, 29 Dec 2017 19:11:22 +0000 "Brian L. Stuart" <blstu...@bellsouth.net> 
> wrote:
>>  I'm at the same point I usually am when getting ready to teach my winter 
>> term OS
>> course. 
> 
> Why teach about Inferno? Just curious.

It works out to be the sweet spot where a lot of considerations come
together.  First, I like to teach OS from an internals point of view.  I
feel that one should understand how one's tools work before using
them.  Second, like a lot of people of my generation, the way I really
learned about operating systems was from Lions commentary on
6th Edition.  For years, I had been thinking about writing an OS text,
but had been teaching from Tanenbaum using MINIX.  It was getting
somewhat problematic in the days when no one was running VMs
for everything and students were getting to where they didn't know
how to partition drives and run other OSs.  Then when Vita Nuova
released the Inferno source, it was like all the pieces fell into place.
It's well-written and carries a lot of the same ideas as Plan 9.  Students
don't have to allocate any extra hardware or even configure a VM.
It's small and simple enough that we can cover all the major elements
of it as well as the general principles in one term.  But they're able
to get some exposure to the internals of a real system and not just
something created for illustrative purposes.

With the ubiquity of VMs these days, a good argument could be
made for using Plan 9 in a VM for the course.  Maybe someday
I'll look at adding Plan 9 chapters to the book, but at least for now,
I'm finding Inferno works quite well.

BLS

Re: [9fans] Inferno on Plan9

[Brian L. Stuart]

On Fri, 12/29/17, G B  wrote:
> I used Inferno from bitbucket.org but wasn't able to build
> on FreeBSD 11.x/amd64 so I just reverted back to FreeBSD
> 9.3/i386.  But I may try to build using 11.1/i386 with
> gcc.  I'll have to use KVM on OpenIndiana to try it
> though since I don't have a spare physical machine at
> the moment.

Don't go to any trouble on my account.  I'm at the same point
I usually am when getting ready to teach my winter term OS
course.  I've got it built, but without the X11 support on my
FreeBSD machine.  It does build and run on our Linux cluster
with the X11 support though, so I can at least demonstrate
it to the students there.

And for the record, the fix to the missing FPxxx constants
was to copy over the defines from the MacOSX version of
the lib9.h file.

I had given some thought to adding amd64 support in at
least the hosted versions, but as usual the round tuits have
been in short supply.

BLS

Re: [9fans] Inferno on Plan9

[Brian L. Stuart]

On Sat, Dec 23, 2017 at 7:13 PM, G B  wrote:
> I've installed Inferno on FreeBSD but how do you build it for Plan 9?  The
> makemk.sh file and without looking, I think the mkconfig file too, reference
> gcc.  And the makemk.sh has /bin/sh.  Do I have to install a Bourne or Korn
> shell plus gcc from contrib to compile?

Which version of FreeBSD did you use, and did you use the
Inferno on bitbucket?  I'm finding it a long way from building
out of the box there these days.

BLS

Re: [9fans] The Case for Bind

[Brian L. Stuart]

On Fri, 9/15/17, Marshall Conover  wrote:

> I'll start digging in to see what I can do. I think I jumped the
> gun by trying to contribute a feature, ...

On this point, I'd suggest a slight shift of perspective.  This is something
that I've tried to convey both to collegues when in industry and to
students when teaching.  Don't think in terms of implementing features.
Think instead of implementing mechanisms.  The mindset where every
feature is implemented with its own mechanisms is the reason so much
software is so poorly engineered.  Witness the browsers mentioned
earlier.  Good engineering involves designing and selecting a good
set of simple mechanisms that when used in various combinations
provide a rich set of features.  If a mechanism doesn't fit, don't include
it.  Remember that perfection is achieved not when there's nothing
left to add, but when there's nothing left to remove.

Bringing this back to bind, I wouldn't think of bind itself as a feature.
However, when the bind mechanism is used in conjunction with the
union directory mechanism and the architecture environment variable,
the feature of sane multi-architecture binary handling emerges.  No
where in the source of the shell or the kernel or anywhere else is
there code specifically designated to make it possible to run the
correct binary based on the architecture.  Of course, there are
other ways of accomplishing this feature, such as a path variable,
but the beauty of this approach is that all of the mechanisms involved
also find application in other features.  For example, bind and per-
process name spaces make possible the elegance of rio which
in turn provides the feature of recursively running rio inside a rio
window, something that takes a lot of special effort in X.  Likewise,
when bind is used with import, you can get a particularly elegant
form of network gatewaying.  So I suggest not thinking of bind as
a feature, but as a very general tool for building features.

One objective when implementing a mechanism is that is reduces
the amount of code in other places by more lines than it takes
to implement the mechanism.  There are two major reasons why
it's important to keep the number of lines of code down.  First,
every line is a potential bug.  To a first approximation, the fewer
lines of code the fewer places where you might have bugs.  Second,
every individual and organization has a maximum level of complexity
that it can manage.  Once that point is hit, all new releases merely
rearrange the bugs.  They don't really make the product any better.

A well designed set of mechanisms is like a set of basis vectors
and each point in the vector space is a potential feature.  If your
set of features isn't larger and richer than the set of mechanisms,
then you should go back and rethink the set of mechanisms.  So
when adding a mechanism, you want to make sure you're adding
a new dimension to your feature space.

BLS

Re: [9fans] Terminal possibliities...

[Brian L. Stuart]

On Sat, 10/1/16, James A. Robinson  wrote:
> Honestly I had been assuming one of those usb battery packs would work. :)

They work pretty well.  One I tested with a B+ and a 3.5" LCD screen
lasted about 4 hours before it crashed.  I should time it with a 3 and
one of the DSI interface 7" LCD screens.

BLS

Re: [9fans] Is 9Fans dead or alive

[Brian L. Stuart]

On Tue, 8/23/16, Brantley Coile  wrote:
> We haven’t stopped using it, but then again, we don’t talk much on the
> list.

I can say this particular 9 fan isn't dead...just aging.  My main file server
here at home runs Plan9, but with my own file system, rather than Ken's.
My auth server is a Raspberry Pi B running Richard's port.  I run 9vx as
a terminal taking its root from my file server daily, and run it with a local
root at the office.  There's another older Pi B running stand-alone at the
office.  I tought a course last fall using Plan9 on Raspberry Pis, and I still
use Inferno internals to teach my undergrad OS class.  Plus one of my
students did an independent study last year starting a port to the Banana Pi.
So at least in my little world, Plan9 is very much alive and being used.

BLS

P.S.  On the other hand, the last six months my little world has included
a lot of activity related to the ENIAC.  So YMMV.

Re: [9fans] More about /dev/draw

[Brian L. Stuart]

I'll try to answer several questions here together.

> I see an image at bell labs for the raspberry pi. 
> http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz
>
> I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs 
> for sale. Will either one work with that image?

I might be mistaken, but I don't thnk that image has the few little
changes necessary for the Pi3.  The kernel file contrib/miller/9pi2
might have the update, but the sources in contrib/miller/9/bcm
are the most current.

> Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a 'sub 
> driver'? not 'usb driver', or is it? The audio out is broken, but it's 
> your fault? How is that?

Feel free to correct me, Steve, if I get anything wrong here.  I think it
was a typo referring to USB.  I'm not sure if it's the same one that's
causing problems with serial adapters, but I've run into one that I
keep intending to track down when I've tried to use USB 802.11
adapters.  As for the audio, I'm pretty sure it's the same position many
of us are in.  We intend to do some work on supporting it, but in the
words of the late Prince, this thing we call life gets in the way.

> Actually, looking at the back of the monitor, it has an analog vga 
> plug-in and a similar sized digital plug-in, but no HDMI. Can I still 
> use it with Raspberry Pi Plan 9?

As trebol said, if it's a DVI interface, then a simple adapter from HDMI
to DVI will work.  That's the way I run one of my Pis as the office
every day.  A typical DVI connector on a monitor looks like this:

http://www.publicdomainpictures.net/view-image.php?image=12589

> On another tack ... I have installed plan 9 from user space on my debian 
> machine, and sam and acme seem to open and work ok. But when I type rio, 
> I get ...
>
> $ rio
> rio: it looks like there's already a window manager running;  rio not 
> started
>
> So, rio under plan 9 from user space (p9port?) wants the the whole 
> display?
>
> I cannot run xfce and have rio in a window?

Correct.  The design of the Plan 9 windowing system is such that the
ability to run another instance of the windowing system in a window
falls out very elegantly.  The same is not true of X.  There, each display
has a single window manager.  As Erik noted, there's xnest that allows
a display to be nested in a window of another display, though I've
never really played with it.  I got scared enough the last time I looked
at the internals of a regular X server.  I'm not sure my old brain could
handle xnest.

BLS

Re: [9fans] Pi Hats and i2c

[Brian L. Stuart]

On Wed, 3/9/16, Vasudev Kamath  wrote:
>> The second talks to the MMA8451 3-axis accelerometer:
>>
>> http://cs.drexel.edu/~bls96/plan9/mma8451sa.c
> 
> This link gives Forbidden message (403)
 
Oops.  I had the mode set wrong.  Try it now and see if works
better for you.

BLS

Re: [9fans] Pi Hats and i2c

[Brian L. Stuart]

On Wed, 3/9/16, Anthony Sorace  wrote:
> Anyone have any example code using the i2c interface on the pi
> I can look at? I'm playing around with several of these, and am not
> getting the results I expect (data getting out, but the hats aren't behaving
> like they're getting the same bits I think I'm sending).
>
> More generally, anyone got any of these hats going? I'm
> starting off with the Sense Hat, since it exposes everything
> on it via the i2c.
 
I haven't done anything with the hats, but I do have a few bits
of I2C code that go along with the driver modifications I posted
a little while back.

The first does a little lightshow on a square LED array from Adafruit:

http://cs.drexel.edu/~bls96/plan9/lightshow.c

The second talks to the MMA8451 3-axis accelerometer:

http://cs.drexel.edu/~bls96/plan9/mma8451sa.c

This latter one illustrates the subaddressing features.

BLS

Re: [9fans] Wireless on the Pi?

[Brian L. Stuart]

On Sat, 1/9/16, Anthony Sorace  wrote:
> Anyone got anything? USB dongle we can drive, or an ethernet bridge
> folks have had good results with? WiFi with WPA2 is ideal, but the only
> hard requirement for my use case is power: it needs to either draw directly
> or be able to draw power via USB.

Not yet.  I've taken a look at a couple of devices, but I've only had time
to get far enough to find that usbd seems to have trouble reading the ID
information out of both of the units I've tried.  I don't see any time coming
up soon when I'll be able to spend on it.

BLS

Re: [9fans] rpi emmc

[Brian L. Stuart]

On Sat, 1/2/16, David du Colombier <0in...@gmail.com> wrote:
> > in diffing bls' version and sources, i see some significant
> > differences, but it's not clear which one is more up-to-date.
> 
> Brian Stuart's version is more up-to-date.
> 
> Brian Stuart based his changes on the latest changes from Richard
> Miller, available in /n/sources/contrib/miller/9/bcm.
 
I'm pretty sure that file is unchanged from Richard's latest version
on contrib.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

On Fri, 1/1/16, erik quanstrom  wrote:
> i'm looking @ the gpio interface, and i wonder what the recommended
> technique for sampling a pin might be from a shell script?

I haven't really used it in shell scripts, but if I were going to do
so, I'd probably write up a little utility to take a hex string and
a bit number and do the 'and' on it.  Then feed that with the
result of dd to get exactly one sample from devgpio.  On the
other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk)
have some bit-wise operators I'm forgetting, use that.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

On Wed, 12/30/15, Skip Tavakkolian <9...@9netics.com> wrote:
> > - Enhancements for I2C and SPI
> 
> is there an updated devrtc3231.c, or a conventional user space
> fs, that uses the new i2c?

Yes, there's a devi2c userland interface ported over from Inferno.
That's what's being used to drive the robot in the video clip.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

On Mon, 12/28/15, Anthony Sorace  wrote:
> And yes, I’d be interested in seeing your
> slides, although you’ve already given me
> enough to keep my busy for a bit.
 
Anthony,
I've put the slides up in the directory at:

http://cs.drexel.edu/~bls96/plan9/

The class met one night a week and we have 10 week
quarters.  So there are only 9 sets of slides.  There's not
a lot of textual meat in them.  I tend to have a lot of figures
I talk over with some outline-level textual material.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

> Excellent.  I had suspected that statement was too restrictive, but hadn't
> seen the errata or gotten around to checking on a scope.  I'll update that
> today.
 
New versions posted.  spiclock() now rounds the divisor up to the smallest
even number that results is a clock rate less than or equal to that requested.
Let me know if you run into anything else that needs attention.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

> but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
> has an erratum suggesting "power of 2" should be "multiple of 2".  I have
> been using a default divisor of 250 for a 1MHz clock, and that's the frequency
> I see on my oscilloscope.

Excellent.  I had suspected that statement was too restrictive, but hadn't
seen the errata or gotten around to checking on a scope.  I'll update that
today.

Thanks,
BLS

[9fans] Pi updates

[Brian L. Stuart]

A few months ago I brought up the question of small
platforms suitable for a course on small/embedded
computing.  If you recall the conversation, with input
from the collective wisdom, I decided to use the Pi.
At that time several people asked if I could share
any results from the course that I'm able to.  I've
finally finished putting some of it together in a form
that's useful.  In

/n/sources/contrib/blstuart/pi/ ...
http://cs.drexel.edu/~bls96/plan9/pi/ ...

are a collection of changes with all the changes
collected into a tarball:

/n/sources/contrib/blstuart/pi.tgz
http://cs.drexel.edu/~bls96/plan9/pi.tgz

The changes include:
- Richard's post 9pi.img changes on contrib
- I2C and SPI contributions from Steve Simon with the
I2C support ported from Inferno
- Enhancements for I2C and SPI
- Devgpio driver
- Man pages for I2C, SPI, and GPIO
- Support for a 320x480 SPI TFT display
- Enhancements to the USB keyboard support to handle
the Rii k12 keyboard/trackpad combination

I've also posted a little video (apologies in advance for
the quality, or lack thereof) of a Pi with the TFT screen
and k12 keyboard controlling a PiBog vehicle my wife
gave me for Christmas:

http://cs.drexel.edu/~bls96/plan9/robot9.mp4

I'll look into making the slides I used in the lecture
available if there's interest.

There are some rough edges, but hopefully it might be
useful to some.

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Fri, 8/14/15, Brian L. Stuart blstu...@bellsouth.net wrote:
 The fundamental issue ... hwdraw().

Tonight's update: Forget what I said last night about hwdraw()
and the difficulty of connecting into the devdraw/memdraw/screen
stack.  I had one of those embarrassing how did it ever work
bugs.  Now hooking into hwdraw() and flushmemscreen() works
pretty well.  With an environment variable in cmdline.txt, it boots
either expecting an HDMI monitor, or the little LCD screen.

A little more playing around attempting improvement and then
I might take a crack at supporting the touch screen.

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Sat, 8/15/15, Steve Simon st...@quintile.net wrote:
 Vncserv must do something similar, maybe that is worth looking at.
 I went down a similar route but am planning to just address
 the display as a different type of device, rather than as a plan9 display.

Good point.  Hadn't thought about that.  I'll take a look and see
if it has anything that might help.
 
 Your progress is very impressive, my project stalled - I must get back to it.
 
The other option I've been thinking about since late yesterday
is to create a variant of devdraw (or add hooks into the existing
devdraw) that allows it to shoot off a request to another device
for every screen update.

My ideal for this scenario is to have a single kernel image that
will simultaneously display on both the HDMI port and the SPI
display.  Then add some bits to boot.rc so that at boot-time, the
user can indicate whether they've got the SPI display installed
and whether to set the geometry and fonts accordingly.  Some
of that may end up being a potential project for students in the
class to do :)

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Sat, 8/15/15, hiro 23h...@gmail.com wrote:
 cute, you should ship with fresnel lenses, then the reference is complete:
 http://www.wikinoticia.com/images2//s2.alt1040.com/files/2011/11/Brazil2-800x528.jpg
 
rotfl...   I hadn't made the association until you mentioned it.
I may have to mention the Brazil branch of development and
show them the picture in class.

 On the other hand you shouldn't underestimate the usefulness of a
 thinkpad (e.g. x61) for students. They are cheap these days if you get
 them used, and this could get your university a badge for ecological
 behavior.  At least it would be in the same price league as rpi + LCD
 + keyboard + mouse + case.
 
True.  The focus is more aimed at understanding embedded systems,
microcontrollers, and SoCs more than Plan 9 per se, and I expect
most students will use an existing HDMI or VGA monitor.  Part of
my motivation for this is as a less expensive alternative for any who
don't have access to a spare monitor.  Of course, they're not going
to get the full embedded experience.  There's just not enough time
to develop a custom piece of hardware and get them comfortable
with bare metal programming.  (Hence why Im calling the course
Computing in the Small rather than Embedded Systems.)  

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Sat, 8/15/15, Joseph Stewart joseph.stew...@gmail.com wrote:
 Brian, does your uni let you publish your curriculum or course notes?
 Is this something you've ever considered?

I should be able to do at least something along those lines.  There
are corners of the university that get twitchy about making available
for free what online students pay for.  But most of us take the more
traditional academic view that the whole point of the exercise is
to spread knowledge as widely as possible.  Of course, whether
there ends up being anything worth making available remains to
be seen :)

BLS

 
 
 
 

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

 I have tried to email BLS but fear I am being spam filtered... you there?

I did get one message from you, and replied earlier today.  Hopefully
it got through.

A little more update on recent pi playing.  I've been working on a
little toy the last few days, namely one of those small SPI driven
LCD panels:

http://www.adafruit.com/products/2441

As of this evening, I've gotten it sort of running alongside the
HDMI display showing the upper left corner.  Here are a few
pics of it in operation:

The Pi with the display connected to a keyboard and mouse:

http://cs.drexel.edu/~bls96/9pitft1-s.jpg

and a couple of pics of the display showing acme running:

http://cs.drexel.edu/~bls96/9pitft2-s.jpg
http://cs.drexel.edu/~bls96/9pitft3-s.jpg

It's a long way from being usable though.  The fundamental issue
is that there appears to be a very deeply embedded assumption
that a screen must be memory mapped.  I tried hooking into
the hwdraw() routine in screen.c, but it seems that not every
change to the screen memory space gets reflected in a call
to hwdraw().  For the pics, I've got a version that periodically
copies the whole of the appropriate area of the Memimage
to the LCD panel over the SPI port.  Obviously, that's too slow
and too resource-hungry to be practical.  Hopefully, I'm missing
something and there's an elegant way to graft a non-memory
mapped display into the devdraw/memdraw/screen infrastructure.

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Wed, 8/12/15, Skip Tavakkolian 9...@9netics.com wrote:
 the gpio pins don't seem accessible through a filesystem api
 like i see in plan9-bcm (unless i've missed something).

I'm pretty sure it's not there.

  it would be great to merge that capability in.

I've made a start on that this afternoon.  I took the devbcm from
plan9-bcm and stripped it down to just the gpio parts and
renamed it devgpio.  I've now got a B+ running with Richard's
latest code that includes I2C and SPI and a first cut revision of
devgpio.  I'm watching an LED I wired up to it blinking driven
by a program in user space as I type this.

BLS
 
 

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Wed, 8/12/15, David du Colombier 0in...@gmail.com wrote:
  Is all that on sources somewhere or accessible otherwise?
 
 Richard's latest Raspberry Pi repository is available here:
 
 /n/sources/contrib/miller/9/bcm

Cool.  Somehow I missed that.  I'll pull it and play with it.  Using
the github plan9-bcm devbcm, I've gotten as far as blinking an
LED, but if there's already working I2C and SPI code, I've got
devices that need to talk that.

Thanks,
BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

 Richard has an i2c and spi driver for the pi. I grafted the inferno
 i2c file system interface on top of Richards driver, though
 the sub addressed reads are awaiting my return from
 holiday.

Steve,
Is all that on sources somewhere or accessible otherwise?
Last night, I pulled devbcm from plan9-bcm on github and
folded it into the latest pi image Richard posted on sources,
but I haven't done anything other than compile and boot
a kernel with it yet.  I've ordered a few toys to play with
including a little 3.5 LCD with touch screen that talks SPI.
So I'm going to try to get that up and running soon.
 
 I would love a
 similar machine with Gbit ether and 2 or 3 sata 3s to
 replace my ageing file server.

Same here.  In fact, I've ordered a Banana Pi to see just
how close it does come to being compatible.  I'll let everyone
know if it does boot the rpi images.

As an update to the whole thing, I've decided to go ahead
and use the Raspberry Pi at least this term.  Given the time
available, I suspect I'd get too caught up in getting a stable
port running on anything else and not do what I need getting
classes prepared.  If I teach this again sometime, maybe I'll
get a chance to do more.

I will say I very much like the documentation that TI has for
the SoC in the BBB, especially compared to what passes
for Broadcom documentation.  The reference manual for
the AM335X processor is nearly 5000 pages.  And there
are several other things I like about the BBB over the pi,
but who knows when my supply of round tuits will allow me
to spend much time working on it.

My thanks to everyone who has given me suggestions.
There are definitely some new machines I hadn't seen
before that I'll be checking out.

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Thu, 8/6/15, lu...@proxima.alt.za lu...@proxima.alt.za wrote:
 Olimex in Bulgaria manufacture and market worldwide a very wide
 range of AVR and ARM based boards and peripherals.  They target
 the DIY market.  Pay their site (olimex.com works for me) a visit.

They do look interesting, and I like their intention to keep things
more open than Broadcom does.  Unfortunately, especially with
their vacation, I fear that the time between now and the start of
the term is too short for me to get one, familiarize myself enough
with it to teach it, get something more interesting than Linux
running on it and work out how to get them into the hands
of the students.  But if I ever do run a similar course again in
the future, I'll definitely look at them far enough ahead of time
to consider using them.

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Wed, 8/5/15, Charles Forsyth charles.fors...@gmail.com wrote:
 I think the big advantage of the Rpi or Rpi2 (for speed,
 memory and cores)is that there's a wealth of published
 projects for them, including hardware ones, and other stuff,
 and they aren't likely to go away. It's true that lacking SATA
 and Gb Ether makes it harderto use them for certain applications
 (except as demos, alhough there's a Kickstarter project for
 mSATA),but if you're doing Computing in the Small both SATA
 and Gb are perhaps optional.

I am kind of leaning toward the RPi at the moment for reasons
very much along those lines.  Though I'm probably going to
order at least a Banana Pi for my own playing around.  If I
read their propaganda correctly, it should run the OS images
that the RPi does.  If so, I'm really curious to see how close
Richard's Plan9 image comes to running on it.  And I do still
need to do some playing with the BBB I recently got.  In terms
of the RPi though, as of yesterday, my auth server is now
running on an RPi, replacing a nearly 20 year old NEC laptop.

 I'm glad you asked, though, because I hadn't seen the APC Paper.

It is a really cute little machine.  I'm tempted to get one of
those to play with too.

Too many toys, too little time...

BLS

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

On Wed, 8/5/15, Skip Tavakkolian skip.tavakkol...@gmail.com wrote:
 RPI's running something like plan9-bcm (check github) where gpio
 is exposed should work. I'm going to try plan9-bcm this weekend;
 i'll keep you posted.

Thanks for the pointer.  I'll definitely check that out.  I'm hoping to
expose them to a little bit of working in the kernel anyway, but
don't want to take so much of the quarter's time as to get them
to the point where they can write their own drivers.  So depending
on where plan9-bcm stands, it might be just right.

 I like ODROID hardware, but obviously there
 isn't a Plan 9 port for it.

True.  Though in looking into some stuff on the Banana Pi,
I've seen indications that it supposedly can run at least one
ODROID image and it claims to be basically RPi compatible.
If all that's true (and things work out ideally) the Plan9 RPi
port might not be all that far away from running on it.

 Arduino Yún (MIPS+AVR) could make a cool device for Plan 9,
 but the MIPS part of the hardware is closed.

I've had a pretty similar reaction to that one.
 
 On the smaller end of the scale, I've just started porting lib9p
 to esp8266. I'm using ESP01; it is a cheap yet very capable
 device.

Very cool.  I'd not seen these before.  Keep us posted on your
progress on it.  that would be a lot of fun to play with.

BLS

[9fans] Small Plan 9 Platforms

[Brian L. Stuart]

I'm teaching a special topics course this fall I'm
calling Computing in the Small.  Right now, I'm
leaning toward conducting it on a platform that
runs Plan 9.  I'm looking for something based on
ARM or MIPS and that has some useful connection
to the external world in the form of GPIOs.  SPI,
I2C, and analog I/O would be nice to have too.
Obviously, the Raspberry Pi is a candidate.  What
are some others?  I've seen some code in the
source tree for the BBB.  Has anyone tried it out
to see what is and isn't there?  How about the
Banana Pi?  The SATA port on it is quite appealing.
Some of the other options I've been looking at
include the VIA APC Rock and Paper, the Phytec
Cosmic, the CubieBoard, the Odroid, the Riotboard,
and the Wandboard.  Has anyone done anything
on porting Plan 9 to any of them?  Are there others
I'm missing that would be good targets for such a class?

Thanks in advance,
BLS

Re: [9fans] ssh handshake failed

[Brian L. Stuart]

 trying to connect from 9atom via ssh (v2) to my linux machine I get:

 ssh: dial: handshake failed
 
 What should I check that might have gone wrong?
 (The machine is otherwise accessible from other systems via
 ssh.)

The first thing to check is whether the Linux box is configured to
do password auth or just keyboard interactive auth.  It seems
that OpenSSH these days defaults to having real password auth
turned off, but keyboard interactive turned on.  It's usually implemented
so that it looks the same to the end user, but the protocol is
different.  The SSHv2 implementation does not currently support
keyboard interactive.

Having said that, I seem to remember that the handshake failed
error actually occurs before you get to the auth stage.  It's very
early in the negotiation when the two sides exchange identities
and supported versions.  It's possible to run the tunnel with debugging
turned on and see what is being exchanged and what is being
complained about.  Similarly, you might look at logs on the Linux
side to see if there's something it's complaining about.

BLS

Re: [9fans] ssh2 (at least the legacy version) seems incompatible with

[Brian L. Stuart]

 ok, i found some more diagnostic messages in /sys/log/sshdebug:
 ...
 The problem might be that `dh.c` has an empty implementation of `dh_client142`
 ...

Ingo,
I must admit to being the guilty party for the SSHv2 implementation.
Though Geoff gets credit for cleaning up what was some of my
uglier code.  It's been over a year since I looked at any of it and
probably closer to 3 years since touching the crypto part.  However,
I'll take a look and see if I can get an implementation of the group 14
stuff in place, or at least not have it advertise something it doesn't
do.

BLS

Re: [9fans] [Solved] Anonymous function formal parameter

[Brian L. Stuart]

 int
 trans(int c, char *)
 {
 
 That parameter seems not to be used inside. That may answer
 the question...

Yes, that is the answer.  By alowing a parameter name to be
omitted, the compiler can warn you about unused parameters
without having to add clutter that explicitly says, I'm ignoring
this parameter.

BLS

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

[Brian L. Stuart]

 I'm new to Plan9, using acme/p9p for a couple of months, and
 I want to add plan9 machines to my network. I'm thinking
 that a DNS/DHCP/AUTH server will be an easy step. If this
 machine could have the role of an Internet
 firewall/nat-router it will be even better.
 
 Do you think plan9+raspi can handle this?

While I haven't set one up like this myself, I'm tempted to do so.
I expect the Pi would make a very nice little auth/dhcp/etc
server.  However, to my knowledge, there aren't any NAT
implementations available on Plan 9.  I know it's been worked
on by several people at different times, but I don't think anyone
has a currently packaged implementation.

 What is the recommended size for the SD card for this role?

The databases used for these functions are pretty small, so
I'd be surprised if you filled a 1G card.

BLS

Re: [9fans] The Third Button

[Brian L. Stuart]

 Would it be possible to create the option of merging these two buttons 
 for machines not blessed with the traditional rodent?

If you hold down the right shift key while pressing the right
button, it interpretes that as a middle button press.  I'm not
completely certain, but I seem to remember it has to be the
right shift key and not the left.  The one machine where I
use that is a laptop and I've gotten into the habit of holding
the shift key with my pinky and hitting the right button below
the touchpad with my thumb.  Still not as nice as a real
middle button, but it serves in a pinch.

BLS

Re: [9fans] Plan9 Sources Repository

[Brian L. Stuart]

 you  may edit the wiki yourself to correct these issues.
 
 The Wiki seems to be frozen (i.e., not editable anymore):
  - no Edit button on 
  http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/

It was changed some time back to allow edits only using
the acme wiki interface, rather than a web browser.

BLS

Re: [9fans] Plan9 Sources Repository

[Brian L. Stuart]

        - having an SSH2 server (there is one in 9atom, but I didn't  
  see it in the stock Plan9).

Geoff included the same ssh implementation as 9atom
has in /sys/src/cmd/ssh2 but with some code clean-up.
So the server code is there.  I've been meaning to go
back an reconcile the two different versions, including
some bug fixes in the 9atom version, but my supply of
round tuits is small.

 Are you sure it doesn't have the Heartbleed?
 
For a number of reasons, yes, I am.   The Plan 9 ssh v2
implementation is completely new and doesn't share any
code with either OpenSSH or OpenSSL.  That decision
was made for a lot of reasons, one of which was to make
the system less susceptible to the script kiddies.  While
I certainly don't have the hubris to suggest it is without
flaws, I'm pretty sure its flaws are different than those
of the mainstream implementations.  So one is unlikely
to get very far using a mainstream exploit.

Having said all that, I would not recommend running an
SSH server on Plan 9, unless you have a really compelling
reason.  With all due respect to those who developed
the protocol, its authentication model is not, in my opinion,
as solid as that of Plan 9.  If you want to remotely log into
a Plan 9 system from a foreign system, use drawterm, or
cpu from a virtualized Plan 9 terminal.

BLS

Re: [9fans] Plan9 Sources Repository

[Brian L. Stuart]

 My whole argument goes about the following hypotheses:
 1. increasing the amount of contributions may not scale in
 the current model.
 2. submitting trivial contributions is not trivial for the contributor.

Both of these points seem to come from a mental model
that just doesn't apply to Plan 9.  In earlier messages, you
used the word team to describe the set of people contributing
to Plan 9.  However, in reality, there isn't a Plan 9 team, per
se.  Essentially, Plan 9 is a research system.  It's a platform
and a vehicle for doing systems research.  It is true that it
has been very useful as the basis of products, as infrastructure,
and as a daily-use OS.  However, rather than being its raison
d'etre, Plan 9's utility is a tribute to and the acid test of the
research work done on it.  After all, I'm hardly going to suggest
that a file system I develop is worthy of study or use if I'm
not willing to put my own data on it.  (So yes, my main file
server is running on thetafs, and has been for months.)

Given that the primary function of Plan 9 is to be a research
system, neither increasing numbers of contributions nor
trivial contributions are to be expected.  In fact, it's not
clear they would be particularly desirable.

The flip side of all this is that because it has been very useful,
many of us use it heavily enough that we'd be loathe to
return to a world where we'd have to do without it.  So there
is valid motivation to expand the set of supported hardware,
fix bugs, make it easier to install and use, etc.  While, I'm
not in a position to speak for the principals involved, from
my perspective, both 9atom and 9front are laregely so
motivated.  I don't think I'm speaking out of turn when I say
that the maintainers of both of those systems would be more
than happy to accept contributions to them.  If, in the course
of making such contributions, you reach a point where the
contribution channel could be improved, then contributing
an improved contribution mechanism would be just as welcome,
I suspect.

In other words, welcome to the Plan 9 community.  We'll
be glad to help you however we can.  We encourage and
look forward to seeing any contributions you make that
emerge from what captures your interest.

BLS

Re: [9fans] simplest disk filesystem

[Brian L. Stuart]

 I’m looking for a very simple in-kernel filesystem.

What's motivating the desire for to be in-kernel?  Nearly,
every file system in Plan 9 runs in user space.  All the
ones that have been mentioned do.  The only in-kernel
file system in the labs' distribution is devroot which is
read-only and intended only to provide enough bits to
get the system up and running.  9atom also includes
a devtinyfs that you could take a look at.

BLS

Re: [9fans] simplest disk filesystem

[Brian L. Stuart]

 I’m trying to make a tutorial explaining the code of
 a not too large kernel (9), but there are too many
 things to explain so I have to cut things.  So having
 a simple fs which does not require to explain 9p, the
 rpc, the mount device, etc would be great.

In that case, I'd suggest using devroot since it's useful
to know how things get bootstrapped and having a
small set of files in the kernel image is a handy technique
for embedded applications.  Although it doesn't talk to
any disk devices, you can point to the next tutorial and
explain that most file systems run as user applications
and communicate with the disks by way of 9p.

BLS

Re: [9fans] Question about fossil

[Brian L. Stuart]

 With the trick I am talking about, there is nothing to stop
 you from connecting to N different remote ventis.  In effect
 your local (by that I mean under your control, not necessarily
 on the same machine) venti can be treated as just a buffer!
 
I took a look at some things along those lines a few years
back in the context of file systems aimed at laptops where
the buffer allowed for operation when disconnected from
the main server.  It wasn't strictly tied to venti as a back-end.
There's a paper on it in the proceedings from IWP9 '09.

http://4e.iwp9.org/papers/lapfs.pdf

It would be interesting to build the same sort of thing in
the fossil-venti connection rather than in the 9P path.

BLS

Re: [9fans] Mistake in Plan9 Mercual port?

[Brian L. Stuart]

 ssh2 doesn't work with passwords (at
 least not without changing server
 settings), you need to use keys.

It does work with real password auth, but current OpenSSH
distros default to not allowing real password auth.  They use
keyboard-interactive instead, and it's set up to look to the
user just like password.  But it's totally antithetical to factotum.
I've thought about doing something to make factotum fake
it for the usual case of keyboard-interactive looking like
password, but it'll be later this summer before I could possible
even look at it.  Of course, anyone else who would like to
do it would gain undying gratitude. :)

As it stands at the moment, the two options are to change
the server config to allow real password instead of fake
password, or use the public key auth.

BLS

Re: [9fans] dual boot

[Brian L. Stuart]

 It now
 booted but the username ram didn't have
 any of the rc init files.

There's a script in /sys/lib/newuser that sets
up an initial set of scripts and directories
for a newly created user.  The newuser(8) man
page give more detail.

BLS

Re: [9fans] dual boot

[Brian L. Stuart]

 BTW, I recently got hold of your OS book. Very nice book, especially

 the inferno parts, which was my primary interest when I bought the
 book.

Thanks, Ram.  I'm glad you're enjoying it.  In the midst of
moving and preparing to return to the classroom this summer,
I plan to get the copyright back from the publisher.  There
are some parts that I definitely think I can explain better.
I'd also like to incorporate some material focused on the
issues releated to large numbers of cores.  But it'll probably
be at least the end of the summer before I have any more news
on it.

Thanks again,
BLS

Re: [9fans] growing/shrinking venti arena files -OR- arena file format

[Brian L. Stuart]

 I'm wondering if anyone can shed some light on growing
 and/or shrinking arena files (i.e., disk partitions). 
 With the growing popularity of logical volume management,
 vitrualization, etc., resizing partitions is becoming
 more and more common, and many file systems already
 have resize tools or options to grow/shrink file
 system structures according to changes in the size of
 the underlying device.  I'm wondering what capacities
 (if any) venti has for dealing with inceases or
 decresases in the size of its arena files.

To make sure I understand the question I'll attempt
to rephrase it.  If I have a logical volume containing
an arena partition and I resize that volume to a
larger size, is there a way to make venti aware of
the larger partition and format the additional space
as arenas in the same partition?  If I have understood
the question correctly, I don't think any of the existing
utilities will do that.  In principle, it should be
possible, assuming that you don't add so much that
the arena map won't fit into the fixed 512K map that
fmtarenas creates.  Fmtarenas just writes a partition
header and then loops through all the arenas calling
newarena.  You could probably update the partition
header and call newarena for each arena in the new
space.  There are probably some gotchas that I'm overlooking
at the moment, but that would be the place I'd start.

 Yes, I know that the canonical way to add more storage to a
 venti server is to format and add an ADDITIONAL arena file
 with venti/fmtindex -a.

I'd be inclined to think this is easier and safer
than munging around with an existing arena partition.

 Is there a TECHNICAL SPECIFICATION for the arena file
 format?

The source code would the be most accurate spec on the
format.  I'd suggest starting with src/venti/srv/dat.h
and move on to look at fmtarenas.c.  Calls in it will
lead you to the other files that will be interesting.

 For that matter, any formal specifications for 9P2000

Section 5 of the man pages is the best reference for
this.

 venti protocol would be very helpful, too (for other
 purposes).

The sources are the best place to look for this one
too.

BLS

Re: [9fans] iwp9

[Brian L. Stuart]

 Americans aren't really creative with their city
 names.  They should learn from the welsh. :)

Yeah, we probably do need more where half of the
consonants are silent :)  On the other hand, I
always thought Bucksnort, Tennessee was pretty
creative...  Well, maybe creative is too strong
a word---unusual, at least.

BLS

Re: [9fans] off-topic: why linux lost the desktop

[Brian L. Stuart]

The question is rather: What killed the Plan 9 desktop?
  
  1) Lack of modern GUI and GUI development kit
  2) Lack of Object Oriented GUI configuration tools
  3) Lack of a decent web0browser
  4) Lack of a decent communication/messaging client
  5) Lack of an Office Applications suite
  ...
  ...
  ...
  z) Last, but not the least, hate towards C++ and love for the Go

But that's the list of benefits, isn't? :)

Precisely.  The correlation between what makes something
good and what makes something popular is small but negative.
One of the primary reasons I stopped using Linux was that
it was becoming too mainstream and just like all the
commercial junk out there.

In general, I don't have any objection to reinventing the
wheel.  If no one ever did, we wouldn't have the pneumatic
tire.  But just fiddling about the edges and deciding what
color it should be is the worst of RD sins.  It's BORING.

If you ever watch the TV shows that are competitions of
creative work, the most damning thing a judge can say is
that it's boring.  The same is true of software development
and engineering.  Besides, it it becomes unfun very quickly
if you can't start something new with a clean sheet of
paper at least every few months.

BLS

Re: [9fans] how up to date are the PDF doc files onplan9.bell-labs.com?

[Brian L. Stuart]

 I just activated my Kindle.  I mailed myself the PDF of
 gawk.1 (of course).
 At fit-to-screen it's too small, but rotated and increased
 size it's better.
 
 As an emergency place to keep the Plan 9 manuals, it sure
 beats lugging
 around all that paper. :-)  I'll be experimenting some
 more.

I've done some fiddling with the ms macros to add Kindle
support.  What I have is:

 .  \ Override page/font parameters for Kindle
 .if '\nK'1' \{\
 .nr PS 7
 .nr VS 8
 .nr LL 3i
 .nr TL 3i
 .nr PD 0
 .nr PI 3n
 .nr PO 0.1i
 .po 0.1i
 .nr HM 0.1i
 .nr FM 0.1i
 .ds LH
 .ds CH
 .ds RH
 .ds LF
 .ds CF
 .ds RF
 .pl 4i
 .tl
 \}
 .el \{\
 .po 1.25i
 .nr PO 1.25i
 \}

You activate Kindle formatting by setting the K register
to 1.  The biggest issue I've run into are tables and
figures that need the space of a larger page.  As for
man pages, There's already a register (s) you can set
to 1 to get it format for 9 pages.  That does improve
things a bit in portrait orientation scaled to fit the
screen.

Those might at least give you a good starting point.

BLS

Re: [9fans] SSHv2

[Brian L. Stuart]

 After patching ndb/cs and running
 nfactotum, I'm still having
 some trouble getting the new ssh to successfully login to a
 remote system:
 
 term% ssh2 openbsd
 The following key has been offered by the server:
 ek=10001
 ...
 
 Add this key? (yes, no, session) yes
 ssh2: dial: handshake failed

Unfortunately, the handshake failed error is something of
a catch-all when something fails in the early negotiation
to set up the connection.  To narrow in on what's happening,
could you first kill all instances of sshtun that are running.
Then run a fresh instance of auth/factotum and don't load
anything from secstore.  Then try ssh again.  If it still
doesn't work, kill sshtun again, and run it manually with
a -d option, then run ssh.  You should get quite a lot of
output to stderr and that will hopefully give us some clue
as to what's happening.

BLS

Re: [9fans] SSHv2

[Brian L. Stuart]

 Add this key? (yes, no, session) yes
 ssh2: dial: handshake failed

One other thing that might be instructive is to look
at the logs.  The client side logs will be in /sys/log/ssh
and the server's are often in something like /var/log.
They might have something that will help us pinpoint
where it's getting unhappy.

BLS

Re: [9fans] SSHv2

[Brian L. Stuart]

  The client side logs will be in
 /sys/log/ssh
 
 This was not created on my system.

My bad.  He only uses syslog when he's in the role
of server, not client.

BLS

Re: [9fans] SSHv2

[Brian L. Stuart]

 After rebuilding nfactotum and
 starting it in a fresh window,
 I'm able to login to all of the previously tried remote
 hosts.

For the reference of future search engines I have a guess
on what you might have been seeing.  If in the original
window, you had attempted to run ssh with an instance of
the older factotum bound to /mnt/factotum, then the tunnel
that got started would be running with that one.  Because
the tunnel is persistent, running a new factotum wouldn't
have affected the existing tunnel.  Opening a new window
created a new name space where the tunnel wasn't bound to
/net, so ssh started a new one, and this time the new
factotum was bound to /mnt/factotum so the tunnel is using
it.

BLS

Re: [9fans] SSHv2

[Brian L. Stuart]

 It seems to be failing only when factotum is already
 populated with
 keys (I should point out: keys unrelated to the hosts I'm
 trying to
 login to with the new ssh):
 
 term% sshtun -d
 
 term% ssh2 openbsd
 Verifying server signature
 In rsa_verify for connection: 0
 got error in factotum: unknown role verify
 Key verification dialog failed
 Shutting down connection 0

While it is possible to get it confused with keys already
stored in factotum (the reason the -z option is there), in
this particular case, the unknown role verify from factotum
seems to suggest it's talking to the old factotum.

BLS

Re: [9fans] GSoC application ideas page

[Brian L. Stuart]

  I'd suggest to complete native SSH2 implementation.
  
  ...
 
 Let's not take this one completely off the table yet.  SSHv2
 would be extremely useful in helping open up communication
 with external systems again.

As Erik said, there is a substantial effort here, probably
more than we could expect of a student during a summer.
However, I can now say that the effort has been made, and
something more of an announcement will be forthcoming.
It'll probably be at least a few days, but a native SSHv2
implementation does exist.

  I use to find sshnet extremely
 viable in a mixed network where now I'm just using sshv2 to
 tunnel in overly complicated startup scripts.

There's not a direct replacement for sshnet per se in this
implementation, but here ssh becomes a protocol sitting in
/net.  So it should be pretty easy to tunnel just about
anything, and I suspect that the changes needed to sshnet
would be relatively minor and would cut out all the SSH
protocol bits.

BLS

Re: [9fans] copying over 9P using plan9port

[Brian L. Stuart]

 I can then cd and explore the bell labs sources via
 plan9port, so that
 works just fine.
 
 When I then try something like
 
 cp -ar sources/plan9/sys/src/ape ape
 
 I get an error stating:
 unexpected open flags 050cp: can not open
 ”sources/plan9/sys/src/ape/9src/mkfile” for reading:
 Access denied

Give it a shot without the -a.  I've had a lot of issues
with the strange attribute flags in modern Unices.  The
issues have usually been when writing via 9p, but it's
worth a try to see if that has anything to do with it.
Any idea what the 050 flags indicate on your system?

BLS

Re: [9fans] Announcing Inferno for Android phones

[Brian L. Stuart]

  The Wank E5 was AU$50.
 
 Why is it that I can't quite summon up the courage to do a
 google search for wank phone?

Because it will cost you $4.99 a minute?

Re: [9fans] MetaPost added to kerTeX!

[Brian L. Stuart]

 I will rest on my laurels for the remaining of the week...

You've earned it.  Congrats and thanks

BLS

Re: [9fans] 9vx Binary for Mac OS X

[Brian L. Stuart]

  it should be as simple as 'make 9vx/9vx' issued in
 vx32/src.
 
 knowing the right make target was the stumbling block for
 me too, a few months ago. I'm thinking it should be
 documented. the ADVENTURE file gives wrong instructions (cd
 src; make; make install)

That's what makes it an ADVENTURE? :)

BLS

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Brian L. Stuart]

Ron wrote:
 andrey mirtchovski
 mirtchov...@gmail.com
 wrote:
  This is great!
 
  it is, isn't it? 6 seconds kernel compile, 15 seconds
 turnaround time
  when developing anything in the kernel (with PXE
 boot). beat that,
  modern operating systems :)
 
 yes, I had to help config and build a linux kernel
 yesterday; every
 time I see it I just want to claw my eyes out. And it gets
 worse every
 month ...

Life is too short to configure and compile Linux and
GNU software.

BLS

Re: [9fans] troff macros for typesetting books/longer texts

[Brian L. Stuart]

 Note, that neither plainTex nor troff handle
 cross-references,
 automatic equation numbering, footnote numbering, table of
 contents,
 etc. Nonetheless, mainly these listed features are often so
 needed.
 ... What I am
 trying to get
 is something like eplain, but for troff. And I wanted to
 have a look
 at how some things are to be done. And to not invent a
 wheel, I asked
 for some *simple* macros, which must have been used e.g. in
 the
 mentioned books in my 1st contribution.

I'd suggest digging around for macro sets people created for
various schools' thesis and dissertation formats.  I expect
several of us have done that and have included auto numbering
of chapters, sections, equations, tables, figures, etc.  If
I look hard enough, I might even be able to find the ones I
did 20 some-odd years ago for my master's thesis, but I'm
pretty sure I won't get able to get to it until at least this
weekend.

BLS

Re: [9fans] Plan9 topology

[Brian L. Stuart]

 I could run a headless box as a Plan9 auth/cpu, fs server.
 Then, if I
 want to this Plan9 server, is there a minimum Plan9 install
 that I
 could put on the spare partition that I have?

With this setup available, there are several ways
you can go.  As a lot of people have suggested, you
can install a cpu/auth/fs server on the headless
machine and use drawterm to be a terminal talking
to him.  An even more Plan9-like way of doing it
is to net-boot a Plan9 terminal from your cpu/auth/fs
machine.  If you want to boot your main box that
way, you can without installing anything on it.
From within Linux, you can do the same thing in
virtualbox.  In fact, I have a virtualbox terminal
running right now on my machine.  It's net booted,
taking its Plan9 kernel from a Plan9 machine that
provides DHCP service and it mounts its root from
a Ken FS machine.  At home, I use 9vx taking its
root from a Plan9 fossil/venti file server.

 for a long time: a 486DX running FreeBSD as a mailserver;
 another
 running as a webserver; another couple running primary and
 slave
 nameservers; and one dual-homed FreeBSD box routing and
 doing
 firewall/natd.

The only problem you'd run into there is that Plan9
doesn't currently have a NAT implementation.
 
 The above sounds like a job for Plan9 :) But my point is -
 is that I
 don't need to set up a LAN to enjoy Linux or FreeBSD. Can I
 use Plan9
 standalone in a dedicated partition?

Yes, the default install from the CD sets up a
stand-alone machine.  And for most of us, that's
the starting point from which we configure any
specialized machines such as cpu, auth, or file
servers.  And you can get a pretty good feel for
what Plan9 is about with a stand-alone machine.
However, some parts of the system make a lot more
sense when you experience them in a networked
environment.  Auth is a good example of this.

But whichever path(s) you take, I hope you'll find
Plan9 is a great system, just as we do.

BLS

Re: [9fans] Plan9 topology

[Brian L. Stuart]

 I see! I mis-understood what you meant by Plan 9
 terminal. I thought
 that the Plan 9 Live CD gave you a choice of either
 installing the
 Plan 9 server or a Plan 9 client/terminal. I now see that
 that there
 are terminals available on various OSes to connect to a
 Plan 9
 server.

It has become a little confusing over
the last 20 years.  In a way too brief
way, here are the basic incarnations of
Plan9:

- Natively running the current Plan9 kernel
   - Stand-alone terminal with its own fs
   - Terminal (possibly diskless) talking
 to an external fs
   - CPU, auth, or file server (or some
 combination)
   All of these are running Plan9 as their
   bare metal OS
- Same as above but in a virtual machine,
  such as virtualbox, vmware, qemu, etc.
- Ken's FS: a file server that runs on
  bare hardware
- 9vx: a port of the Plan9 kernel to vx32
  that allows a full Plan9 system to run
  as a user-level application on another
  system, including Linux, FreeBSD, Mac OSX
- drawterm: an earlier port of a limited
  Plan9 kernel that's similar to a terminal
  connecting to a remote CPU server
- P9P (aka Plan9 ports, Plan9 from user
  space): a port of the Plan9 user apps
  to POSIX-like systems
And just for fun these can all play together.
At the moment, I'm using a MacOS machine
that has one file system mounted using
the P9P 9pfuse program.  It's also running
an instance of virtualbox that's net booted
a Plan9 terminal.  There's also an instance
of 9vx running which is accessing the file
system mounted via P9P.  All of these pieces
are talking to a Plan9 CPU server which
in turn uses a Ken FS file server.

  I did see that `wily', an
 Linux ACME
 clone is available. Guess what I did? :)

I remember playing with wily quite a lot
a while back.  With Russ's P9P port of
acme, though, you can run the real acme
as a Linux app too.

 I just checked - it's a 166Mhz P-I with 98M RAM and 4.5G
 HDD. Made a
 good dedicated mail server. May not have enough gonads for
 a Plan 9
 server though.

I wouldn't dismiss it entirely.  My old
Plan9 CPU/auth/file server at home had
a very similar configuration.

BLS

Re: [9fans] Plan9 development

[Brian L. Stuart]

 to a single underlying (OS) platform, but failed (in a
 suprisingly ugly
 way) to cater for different target object formats, even
 though there were
 efforts to do so.  In my opinion - and this is all I
 hold against Plan
 9 - by shoehorning various target object formats in the
 linker/loader
 as options, they spoiled the consistency of the system.

I always had the impression that the object formats
used by the various ?l are more for kernels and the
various formats expected by loaders than for userland
apps.  For userland, I would think the intent is for
there to be a single consistent object format (at least
for a given architecture).

BLS

Re: [9fans] sheevaplug port available

[Brian L. Stuart]

 Wasn't that what we found just last week regarding the
 /dev/sd00/nvram thing?  This is
 on native Plan 9, (er, under VMware), not 9vx or anything
 like that.  The filesystem is
 fossil, not kfs.

The file servers that maintain on-disk file systems
like kfs, fossil, kenfs, etc. all do use groups in
the expected way.  Part of the reason they can easily
do so is that they have the file that lists the groups.
The in-kernel file servers and many of the user space
file servers that don't provide persistent data storage
do not fully handle groups.  This isn't too surprising
since they might well be running without a persistent
disk-based file system present.  So the fossil file
system does use groups, but the server that provides
/dev/sd00 does not.

BLS

Re: [9fans] sheevaplug port available

[Brian L. Stuart]

 I'll check the permissions on /tmp, and I bet you're right
 there.

There's a good chance your /tmp issue is not permissions,
but a lack of /tmp being mounted.  If your hostowner
doesn't have a lib/profile or its lib/profile doesn't
mount /tmp, then you won't be able to write anything
to it.  As has been mentioned, ramfs provides a file
system that lives in memory and defaults to mounting
it on /tmp.  So running it will give you a /tmp even
without fossil being there.

BLS

Re: [9fans] native lbl, long text in troff, bold italics in eqn

[Brian L. Stuart]

 2) I heard and read that the 'ms' troff macros are not
 suitable for
 longer documents (I want to write my PhD thesis), as
 opposed
 supposedly to the 'me' macros (which, however are not in
 plan9, I
 believe). Can anybody give me their opinion?

There should be some macro packages out there that
fit particular universities' requirements.  If you
can't find one that's close to your needs, I think
I can find the one I did at Notre Dame, but you may
have to change things like chapter headings if you
have stricter requirements than ND had.  (I did have
stricter requirements at Purdue, but I used LaTeX
there).  Be forewarned though, this macro package
was written 25 years ago on troff running on 4BSD.
No guarantees that it'll work out of the box with
current troff on Plan 9.

BLS

Re: [9fans] writing to ctl using fprint and write

[Brian L. Stuart]

  Thanks Erik, Sape, and
 Skip.  That was such a STUPID error, and I thank
  you all for the extra eyes.  I think it is time
 for a break and a bowl of
  tea...
 
 relax.  not stupid, subtle.  it takes vigilance
 to keep
 sizeof, nelem, strlen, and the number of characters
 straight.

This is part of why I often recommend (and generally
do myself) that sizeof only be used on types, not
variables:

Foo bar;

use sizeof(Foo) rather than sizeof(bar).  It does
require slightly more work for arrays:

Foo bar[NFOO];

requires NFOO * sizeof(Foo) rather than sizeof(bar),
but I personally think it's worth it to keep the
distinction between sizeof and strlen straight.

BLS

Re: [9fans] Announcement: Fifth IWP9 - Oct 11-13 2010, Seattle WA

[Brian L. Stuart]

  AWESOME!  I will try to round up some friends who may
 never have even seen
  Plan 9 before as well.
  Dave
 
 If we're going to have newbies then maybe an evening
 installfest would be fun.
 
 ron

Good idea.  It might also be worthwhile to introduce
that with an overview of the roles and differences
among: Plan9, P9P, 9vx, drawterm, and Inferno, along
with some examples of how they all get used.  And
some mention of the various virtualization options
might be good to.

BLS

Re: [9fans] crashing 9vx

[Brian L. Stuart]

 OK, somebody sent a hint that it
 might make sense to take the -O3 out
 of the make flags. Done.
 
 Result: I can now get through this command:
 hget -v http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2/tmp/iso.bz2
 |[2]aux/statusbar plan9.iso
 
 without an explosion.

This is weird.  I just built 9vx on FreeBSD without
the -O3.  But instead of being more stable, that
one crashed on startup, like Charles reported.
Namely:

9vx panic: user fault: signo=11 addr=3850cb67 [useraddr=cb67] read=1 
eip=80b973c esp=493ffac0
aborting, to dump core.

With the -O3, the crashes are rare, and seem to be
associated with heavy I/O.

BLS

Re: [9fans] crashing 9vx

[Brian L. Stuart]

 You also have to recompile vx
 library.

I'm pretty sure I did.  I did a gmake clean
followed by gmake 9vx/9vx in vx32/src.  I'm
pretty sure I saw the libraries being compiled
as the compile commands flew by on the screen.

BLS

Re: [9fans] crashing 9vx

[Brian L. Stuart]

 you may be right, but it seems too easy to blame gcc.
 a better fit for the facts so far would seem to me that
 9vx' locking is broken.  the optimization may just
 put
 more pressure on broken locking.

I would certainly agree that the variability of the
crashes feels like a mutual exclusion problem.  The
wide variety of effects of changing optimization
seems to by trying really hard to tell us something.
Of course, after two days of house-hunting I could
probably convince myself that the phase of the moon
is involved.

BLS

Re: [9fans] sources flproto example still accurate

[Brian L. Stuart]

--- On Thu, 5/6/10, Fernan Bolando fernanbola...@mailc.net wrote:

 ...which led me to believe I needed to do an
 pre-authenticated
 connection, but as Skip pointed might not be possible if
 p9p is
 capable of doing authentication.

I'm pretty sure it is as long as you have the auth
server configured and you have factotum running.
I don't have my machine up at the moment, but I
do have that kind of connection as part of my login
script on FreeBSD using p9p.

BLS

Re: [9fans] missing machs unearthed

[Brian L. Stuart]

  My impression is that mp
 tables are getting worse and worse on new
  hardware because vendors assume everyone is
 running an acpi-aware OS.
  
  it's not clear to me that's it's not just general low
  quality,
 
 Does that imply that we can expect the acpi tables to be
 often
 incorrect too?  That would be disappointing.

Well, they are bad enough that FreeBSD (and I assume
others) gives you a way of overriding the one provided
by the vendor.  There are collections of fixed ACPI
tables for various machines out there.

Just to make life more interesting, there's something
flakey about FreeBSD's access of the table in my HP
laptop.  About half the time it boots up and reads the
table happily.  The other half, it will continually
complain that there's something wrong with the table.

BLS