Re: [9fans] Throwing in the Towel

[Charles Forsyth]

i'm curious what straightforward storage structure wouldn't be. trying to
second-guess ssd firmware seems a tricky design criterion.

On Tue, 28 May 2024 at 20:34,  wrote:

> For the napkin calculation: On disk, the IEntry is 38Bytes. Alas, writes
> occur always in (the ssd internal) blocksize. So, essentially (assuming
> 4096 byte blocksize, which is quite optimistic), we have a write efficiency
> of less than 1 percent.
>
> A good firmware in the ssd could avoid needing a new block for the write,
> if all bits are changed in teh same direction by the new data. This is
> defeated by the binary search in the index buckets. The entries must be
> sorted, and the number of used entries is tob updated. So, for each new
> entry the whole (internal) block has to be remapped. Therefore an erasure
> block must be erased after about  1m/4k index writes.
>
> It seems, venti in its current form is a ssd killer, if they are used for
> the isects.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2ca67486c7a13a77-Me67a4d43e72cda0aa878fc21
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] fossil [was: List of companies that use Plan 9.]

[Charles Forsyth]

Fossil will run without venti, but the moment you connect it to a venti, it
cannot be standalone again, as it stands.

On Sat, 18 May 2024 at 14:50, Lucio De Re  wrote:

> Please include me as well. I have an unambitious plan I would like to
> experiment with. And the most advanced version of Fossil would fit
> nicely into that. Also, am I mistaken in believing that in all of 9legacy,
> 9front and p9p, Fossil and Venti need to be treated as a bundle, possibly
> starting with Venti as one component, but with Fossil quite dependent on
> Venti?
>
> Lucio.
>
> On Fri, May 17, 2024 at 9:16 PM David du Colombier <0in...@gmail.com>
> wrote:
>
>> > Responding off list shortly :)
>> 
>> I'd like to be included into the discussion as well.
>> 
>> Thanks.
>> 
>> --
>> David du Colombier
>
>
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
>
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-Meb7ca5e2f90ca82dcee4f634
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] one weird trick to break p9sk1 ?

[Charles Forsyth]

>
> (OK, I know that's delusional because I've installed go. But maybe
> not for much longer, as google seems determined to introduce python3
> as a dependency.)


wat!??

On Mon, 13 May 2024 at 13:48, Richard Miller <9f...@hamnavoe.com> wrote:

> cro...@gmail.com:
> > As for the proposed strawman `p9sk3`, I fail to see what advantage
> > that would have over dp9ik
> 
> My point was only about the advantage of p9sk3 over p9sk1, not to
> compare it with anything else. The intent was to counter the implication
> that p9sk1 is terrible and completely broken, by suggesting that the
> threat of brute-forcing the entire keyspace can be mitigated with a
> small, local and very easy to understand variation to the ticket service
> (with no change to the protocol on-the-wire).  Of course it doesn't
> mitigate
> the problem of users negligently choosing weak passwords.  dp9ik has the
> extra advantage of doing that too, by removing the opportunity for offline
> dictionary attacks.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Ma0d5d024db1989861dc8d9aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Interoperating between 9legacy and 9front

[Charles Forsyth]

>
> (if it was all that easy, why was it discarded entirely?


I suspect no-one wanted to maintain it (in 9front).

> Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M2effb4edbec9b284fda30ced
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Name duplication in union directories

[Charles Forsyth]

it isn't used

On Sat, 4 May 2024 at 22:45, Alyssa M via 9fans <9fans@9fans.net> wrote:

> Is the presence of the duplicate names when reading a union directory
> actually needed/used anywhere? Or is it just an artefact of the most
> straightforward implementation for Plan 9?
>
> I ask because I'm implementing the Plan 9 system calls on my own OS. If I
> don't have to implement the name duplication in union directories, then I
> may be able to get away with less code.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf4c3dc658874afea-M414d2054d51b175b95c889ed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] boot order on separate venti/fossil machines

[Charles Forsyth]

Fossil once attached to venti can't serve without it, so venti must arrive
first.
My machine is fossil+venti, so not quite what you asked about, but the
mechanism would
be similar. The server boots the kernel from 9fat. (If I wanted to pxe boot
the venti,
I could push the boot server problem back to a boot server, perhaps the
auth server.)
The kernel uses configuration pcfs, which contains enough in bootdir to
start and run fossil,
which checks $venti (set in plan9.ini) to see if it should run that first,
if local. If venti isn't
local, it sets up the network so fossil can dial it.
/sys/src/9/boot/local.c organises that. I don't think a configuration is
provided
that starts just venti, but some of the pc* configurations in /sys/src/9/pc
hint at ways to
make various custom systems.

(9front's /sys/src/9/boot use rc scripts, which is much easier to change,
but it doesn't provide fossil at all.)

On Sat, 20 Apr 2024 at 08:21, Marco Feichtinger  wrote:

> I am curios.
> In an environment where you have separate machines for fossil and venti,
> do you boot fossil first, and let venti pxe boot over it,
> or do you boot venti first, with a small, local, fossil partition?
> 
> -marco

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc731bf1d8c36e0a4-Md17bb5ecf553fcbfb1b3eae9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

Briefly, no. It's a constraint language, and it happens to be able to
produce yaml etc as a side-process.
I've used it to enforce constraints in a tax application. "Enforce"
understates what actually can be done.

On Tue, 16 Apr 2024 at 20:31, G B via 9fans <9fans@9fans.net> wrote:

> Isn't Cue YACL (Yet Another Configuration Language)? Absolutely no way one
> can deprecate YAML and just use Cue, so all one is doing essentially is
> adding one more thing to learn and keep updated. And since it hasn't
> released 1.0, what happens if the new YACL never materializes but was
> adopted? Good luck ripping that out to return to YAML.
>
> On Tuesday, April 16, 2024 at 09:26:28 AM CDT, Charles Forsyth <
> charles.fors...@gmail.com> wrote:
>
>
> Although cue itself is more generally useful, applied that way it's a
> coping mechanism that indeed doesn't address the fundamental point:
> like those Sendmail configuration languages that compiled down into the
> rewrite language instead of just replacing that.
>
>
> On Tue, 16 Apr 2024 at 15:19,  wrote:
>
> Quoth Charles Forsyth :
> >
> > it's been a little while since i first looked at it, but i think one of
> the
> > example application is exactly how one might use it to avoid 80k lines of
> > yaml that you must look at directly.
> 
> while it may help -- this is just stacking complexity on top of
> complexity.
> 
> kubernetes may be a tool that some of us need to deal with for
> our jobs, but it has no place in a well designed rethink of the
> world.
> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Me7b04f3e2f6e4c8db91448b5>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M47e060c9bce6265f95ef579c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

Although cue itself is more generally useful, applied that way it's a
coping mechanism that indeed doesn't address the fundamental point:
like those Sendmail configuration languages that compiled down into the
rewrite language instead of just replacing that.


On Tue, 16 Apr 2024 at 15:19,  wrote:

> Quoth Charles Forsyth :
> >
> > it's been a little while since i first looked at it, but i think one of
> the
> > example application is exactly how one might use it to avoid 80k lines of
> > yaml that you must look at directly.
> 
> while it may help -- this is just stacking complexity on top of
> complexity.
> 
> kubernetes may be a tool that some of us need to deal with for
> our jobs, but it has no place in a well designed rethink of the
> world.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M344d24b2cc5ab461b471e97e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

it's been a little while since i first looked at it, but i think one of the
example application is exactly how one might use it to avoid 80k lines of
yaml that you must look at directly.

On Tue, 16 Apr 2024 at 05:30,  wrote:

> Taj Khattra  wrote:
>
> > > > You might find help in culang.org
> > >
> > > DNS can't seem to find that for me 
> >
> > https://cuelang.org/
> 
> Much thanks!
> 
> Arnold

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Ma3ab6cce9db4a39059bfea83
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

yes, sorry, mistyped on a phone

On Tue, 16 Apr 2024 at 04:24,  wrote:

> Charles Forsyth  wrote:
>
> > >  And, if I hear about it being
> > > “declarative” as a virtue, I point to the 81,000+ lines (and
> > > growing) of YAML, that I defy any one human to comprehend.
> >
> >
> > You might find help in culang.org
> 
> DNS can't seem to find that for me 
> 
> Thanks,
> 
> Arnold

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mb8a9a40361e9e1e26d3b509f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

>
>  And, if I hear about it being
> “declarative” as a virtue, I point to the 81,000+ lines (and
> growing) of YAML, that I defy any one human to comprehend.


You might find help in culang.org

On Mon, 15 Apr 2024 at 20:49, Kim Shrier  wrote:

> > On Apr 12, 2024, at 4:56 AM, David Arnold  wrote:
> >
> >> The vetting process needs some work, lads.
> >
> > More heresy than trolling, perhaps?
> >
> > It was thought-provoking for me.  I wished I was there for the bar
> session afterwards.
> >
> > d
> 
> It didn’t read like a troll paper to me.  I periodically go through
> a similar exercise of thinking about how I would re-evaluate
> various Plan 9 decisions given the environment we find
> ourselves in, more than 35 years after the original work
> was done.
> 
> I do have an answer to the question, “Do we really have to
> have our own kernel?”.
> 
> Yes.
> 
> Making decisions about fundamental principles upon which
> you build your system has profound impacts on every aspect
> of the software, including the kernel itself.  Linux is not a good
> substitute for Plan 9.
> 
> And, I take particular exception to recommending Kubernetes
> as a tool for deploying services.  I am having to live through
> Kubernetes hell in my day job.  And, if I hear about it being
> “declarative” as a virtue, I point to the 81,000+ lines (and
> growing) of YAML, that I defy any one human to comprehend.
> 
> I do think it is a good exercise to reevaluate the premises on
> which one builds their systems in order to see if something
> needs to change or a completely different approach is
> warranted.
> 
> I just come to different conclusions than the author of this
> paper.
> 
> Kim
> _
> C++ is an off-by-one error
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Ma63b1c0f14990832dddeadef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

>
> Where’s the link? I haven’t seen one yet for reading papers in advance.
> Still one hour to go…


I haven't read it yet myself, to avoid spoilers, but I thought it was a
record even for Plan 9 that something has disturbed people even before the
workshop opens!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M01f15c2d3f4e4a44193c473c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Charles Forsyth]

>
> Hold your hand, my lord!
> I have served you ever since I was a child.
> But better service have I never done you
> Than now to bid you hold.


(King Lear, First Servant)

I think it's a mistake to split into factions. The collective is small
enough that it's almost like the joke about someone
being so fractious that if they were in a room by themselves, they'd argue
with themselves for practice.

I mainly run a 9 version that's several years old, give or take some
Raspberry Pi HAT devices, just because I've had to
earn my keep doing non-Plan 9 work for nearly 8 years and that Other
contracting has consumed enough time I haven't got much spare time.
 Ada, C++, C#. (Good things too: I suddenly got to develop single page
applications in JavaScript with Vue.js and I quite liked both of those and
immediately rewrote from C# to Go.)

Last iwp9 in Waterloo last year, I was finally able to interact after many
years with both 9legacy and 9front people.
During the summer, I attended a 9front hackathon in Brooklyn, where by
circumstance I wasn't at all useful in the hackathon part,
for various reasons irrelevant here, one of them being an unexpected
transit time between Brooklyn and Midtown,
*but* I did have a chance to interact for the first time with a large group
of 9front people.
Whatever it might have been when 9front kicked off, it now has a structure,
a technical competence, a real interest in 9 ideas,
and lots of people discussing things and beavering away (more than I was).

I've imported 9front code both into the compilers and the kernels, for
instance for embedded wifi support.
It's sometimes not easy on the app and kernel side because there has been
big divergence, but then again, the chief benefit of trade is difference,
so perhaps it's not a bad thing.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M8f845490c918dcc5d22dde02
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iwp9 paper submission ?

[Charles Forsyth]

Ah! So I haven't missed the submission deadline after all!

On Sat, 28 Oct 2023 at 19:13, Edouard Klein  wrote:

> Thanks Ori for the update. Please do not hesitate if you feel I can make
> myself useful somehow.
> o...@eigenstate.org writes:
>
> > Quoth Edouard Klein :
> >> Dear 9fans,
> >>
> >> I tried emailing an abstract to all iwp9*@iwp9.org addresses, but got a
> >> email delivery failure notification back.
> >>
> >> Do anybody know where we stand on the workshop organization ? Is there
> >> anything I could do to help ?
> >>
> >> Cheers,
> >>
> >> Edouard.
> >
> > Short summary -- we're working on it. It's likely to be at a different
> > location than we had initially announced. We're waiting to confirm
> > before we put out the call for papers and specific dates.
> >
> > It will be happening.
> >

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2cf2f3b242100bba-M4897002be9abb2556e1e846b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] /dev/realtime doesn't exist?

[Charles Forsyth]

There's another paper from an iwp9 http://9p.io/iwp9/Real-time.pdf that
might provide more detail

On Tue, 29 Aug 2023 at 18:19,  wrote:

> Quoth dusan3...@gmail.com:
> > I was reading an article about plan9's realtime scheduler edf (
> http://doc.cat-v.org/plan_9/real_time/real_time_in_a_real_operating_system/real_time_in_a_real_operating_system.pdf,
> page 7), and they mentioned using /dev/realtime to create realtime
> processes, but /dev/realtime doesn't exist on my machine (I am using
> 9front). I found a post here from 07 saying something about removing it a
> long time ago, but it got no answers.
> >
> > In proc(3) they mention some commands for configuring realtime processes
> but I don't know if that is to configure an already made realtime process
> or to make one from a regular. How do i make realtime processes in these
> days?
> 
> it's the bits you found in /proc; there are no (longer?)
> any special real time processes; any process can become
> real time by setting up deadlines at any point.
> 
> /dev/realtime isn't needed any more.
> 
> unfortunately, I'm not aware of any programs using it.
> 
> (that may be a good question for the list: where was the
> real time scheduler used, and does any code using it
> survive?)
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0e7a4f73d1eae3b-M6b463332615f9ce69ce32d0b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Charles Forsyth]

It was the different characteristics of hard drives, even decent SATA,
compared to SSD and nvme that I had in mind.


On Sat, 8 Apr 2023 at 15:30, Charles Forsyth 
wrote:

> zfs is very big, complicated and the code looks ancient. I did not enjoy
> working with it.
>
> On Sat, 8 Apr 2023 at 08:51, hiro <23h...@gmail.com> wrote:
>
>> fixing another couple deadlocks makes you finally consider ditching
>> fossil?
>> zfs storage isn't always permanent either, for example if you use
>> encryption or deduplication.
>>
>> On 4/6/23, Lucio De Re  wrote:
>> > On 4/6/23, n...@pixelhero.dev  wrote:
>> >> Quoth Charles Forsyth :
>> >>> fussing about certain things for hard drives that probably don't
>> matter
>> >>> for
>> >>> SSD let alone nvme
>> >>
>> >> I am once again asking you to be more specific, please :)
>> >>
>> >> I have Plans for improving venti for myself, it'd be great to actually
>> >> have a specific list of issues that others have noticed!
>> >>
>> > I presume that fossil doesn't apply special treatment to SSD and NVME
>> > which to my limited understand could be a serious downside. I guess
>> > I'm asking whether one should seriously consider ditching the
>> > fossil/venti combination and consider centralising permanent storage
>> > on something like ZFS instead?
>> >
>> > Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-M3a916ec52a7ef1d354e615bd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Charles Forsyth]

zfs is very big, complicated and the code looks ancient. I did not enjoy
working with it.

On Sat, 8 Apr 2023 at 08:51, hiro <23h...@gmail.com> wrote:

> fixing another couple deadlocks makes you finally consider ditching fossil?
> zfs storage isn't always permanent either, for example if you use
> encryption or deduplication.
>
> On 4/6/23, Lucio De Re  wrote:
> > On 4/6/23, n...@pixelhero.dev  wrote:
> >> Quoth Charles Forsyth :
> >>> fussing about certain things for hard drives that probably don't matter
> >>> for
> >>> SSD let alone nvme
> >>
> >> I am once again asking you to be more specific, please :)
> >>
> >> I have Plans for improving venti for myself, it'd be great to actually
> >> have a specific list of issues that others have noticed!
> >>
> > I presume that fossil doesn't apply special treatment to SSD and NVME
> > which to my limited understand could be a serious downside. I guess
> > I'm asking whether one should seriously consider ditching the
> > fossil/venti combination and consider centralising permanent storage
> > on something like ZFS instead?
> >
> > Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-M0d0a1ec97cd26b13e9294866
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Charles Forsyth]

fussing about certain things for hard drives that probably don't matter for
SSD let alone nvme

On Tue, 4 Apr 2023 at 23:04,  wrote:

> Quoth Charles Forsyth :
> > Fossil works hard to do certain things that now we probably wouldn't
> bother
> > to do.
> 
> Such as?
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-Md583b0e2164eb70218c630e4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Charles Forsyth]

One of the nice things about several of the papers at iwp9 was the implied
or express reconsidering of secondary storage given various types of modern
technology.
Fossil works hard to do certain things that now we probably wouldn't bother
to do.

On Tue, 4 Apr 2023 at 21:44, Charles Forsyth 
wrote:

> It's funny that usually "it wasn't me" is used when breaking things. here
> it's fixing them, but I'm fairly sure "it wasn't me" that fixed it.
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-M9c2d5cbd6cdf66a3a9443d64
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Charles Forsyth]

It's funny that usually "it wasn't me" is used when breaking things. here
it's fixing them, but I'm fairly sure "it wasn't me" that fixed it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-Md75914502384917e733de7a4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Error when running >spell

[Charles Forsyth]

no they're using acme in plan9port

On Fri, 13 Jan 2023 at 13:36,  wrote:

> If ""Sh":fail:'./spell.dis' file does not exist" is your main issue
> and assuming you are probably using acme-sac or acme in inferno,
> you'll want to have a look at os(1) in inferno.
>
>
> On 1/13/23, revr...@mweb.co.za  wrote:
> > I successfully installed plan9port on Ubuntu.
> >
> > It created an acme-home folder for me when I ran acme.
> >
> > Most commands are working fine except that when I try to run >spell on a
> > selection or |rot13 I get these errors:
> >
> > "Sh":fail:'./spell.dis' file does not exist
> >
> > sh: rot13: './rot13' file does not exist
> >
> > I would appreciate any help with this.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T776880ea45b5218a-M5792b7998f44e8268ca922c3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] How can I compile c code written for plan9 in ANIS C compiler

[Charles Forsyth]

If you look at plan9port (eg, https://9fans.github.io/plan9port/), you'll
see how that's done for a good chunk of the application code of Plan 9
(using host C compilers).
It also includes versions of the Plan 9 libraries that will also compile on
other systems.
Indeed, if you install plan9port you should be able to use its mk, 9c and
9l and mkfile structure to compile your Plan 9 code directly (since that's
how the Plan 9 libraries are compiled in plan9port).
The main restriction is that various Plan 9 C extensions aren't available,
so those need to be removed first.


On Thu, 6 Oct 2022 at 01:17, _ resun  wrote:

> Hi there!
>
>
>
> Is there any way I can compile a C code that is written for plan9 using a
> ANSI  C compile? Is there any way to replace the plan9 headers with ANSI
> standard c headers?
>
>
>
> Thank you.
>
>
>
> _resun
>
>
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T422378fc25787720-M69ab07438d3e53337fba4ee2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[Charles Forsyth]

I'm sorry that my original terse reply, which was well meant, stirred up a
hornet's nest.
I simply didn't know that it wasn't to be found in the two
distributions you mentioned
(I did know it was certainly in 9front).

On Sun, 22 May 2022 at 19:18, Charles Forsyth 
wrote:

> You enquired about support for an architecture within Plan 9 on a Plan 9
> list so the context was clear and I reply with the relevant architecture
> string to help you locate it, but get a little lecture about Arm's naming
> scheme (come to think of it, what are Thumb-1 and Thumb-2 called?). Next
> time, I'll insist on the 27B/6.
>
> On Fri, 20 May 2022, 22:27 adr,  wrote:
>
>> On Fri, 20 May 2022, Charles Forsyth wrote:
>>
>> > Date: Fri, 20 May 2022 21:34:05 +0100
>> > From: Charles Forsyth 
>> > Reply-To: 9fans <9fans@9fans.net>
>> > To: 9fans <9fans@9fans.net>
>> > Subject: Re: [9fans] Aarch64 on labs|9legacy?
>> >
>> > It's called arm64
>> 
>> From
>> https://developer.arm.com/documentation/den0024/a/Introduction?lang=en
>> 
>> "AArch64 is the name used to describe the 64-bit execution state
>> of the ARMv8 architecture. AArch32 describes the 32-bit execution
>> state of the ARMv8 architecture, which is almost identical to ARMv7.
>> GNU and Linux documentation (except for Redhat and Fedora distributions)
>> sometimes refers to AArch64 as ARM64."
>> 
>> I would agree that you could use the therm ARM64 as a synonym of
>> Aarch64, but giving me just that response... It isn't even funny.
>> 
>> adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M8607f977bb2ac1eebf6e7a69
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[Charles Forsyth]

You enquired about support for an architecture within Plan 9 on a Plan 9
list so the context was clear and I reply with the relevant architecture
string to help you locate it, but get a little lecture about Arm's naming
scheme (come to think of it, what are Thumb-1 and Thumb-2 called?). Next
time, I'll insist on the 27B/6.

On Fri, 20 May 2022, 22:27 adr,  wrote:

> On Fri, 20 May 2022, Charles Forsyth wrote:
>
> > Date: Fri, 20 May 2022 21:34:05 +0100
> > From: Charles Forsyth 
> > Reply-To: 9fans <9fans@9fans.net>
> > To: 9fans <9fans@9fans.net>
> > Subject: Re: [9fans] Aarch64 on labs|9legacy?
> >
> > It's called arm64
> 
> From
> https://developer.arm.com/documentation/den0024/a/Introduction?lang=en
> 
> "AArch64 is the name used to describe the 64-bit execution state
> of the ARMv8 architecture. AArch32 describes the 32-bit execution
> state of the ARMv8 architecture, which is almost identical to ARMv7.
> GNU and Linux documentation (except for Redhat and Fedora distributions)
> sometimes refers to AArch64 as ARM64."
> 
> I would agree that you could use the therm ARM64 as a synonym of
> Aarch64, but giving me just that response... It isn't even funny.
> 
> adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M853e5a6fd4993355ec0b867f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[Charles Forsyth]

It's called arm64

On Fri, 20 May 2022, 20:37 adr,  wrote:

> Hi,
> 
> has someone done something with aarch64 on labs|9legacy?
> 
> Regards,
> adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M0713116d8bdc8f58091d1ba0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[Charles Forsyth]

it's void* because that can be assigned between other pointer types without
a cast.
x = malloc(sizeof(*x)); instead of x = (T*)malloc(sizeof(*x)); which just
adds clutter.
Similarly it's just free(x) instead of free((void*)x); (or free((uchar*)x)
as I understand your suggestion).


On Sun, 15 May 2022 at 11:59, adr  wrote:

> Hi,
> one of the first thing I noticed compiling in plan9 is that arithmetic
> on void* is illegal. Other compilers treat void* as uchar*.
> Conceptually, it  makes sense. A pointer to void doesn't point to
> any object. But then I've seen the use of void* in functions (like
> memccpy) when the pointed object is going to be processed as a
> byte array. Local uchar*'s are used to do the trick inside the
> function.
> 
> It wouldn't make more sense to avoid the use of void*
> and just use instead uchar* or better still u8int*?
> 
> Some thoughts?
> 
> Regards,
> adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M057b5e29e604b46338b87e89
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[Charles Forsyth]

The short answer is whatever the historical reasons for the current
interpretation(s), it should follow C99 rules to avoid confusion.
One potential catch is that the compilers don't implement C99 rules when
signed and unsigned values meet, but something closer to the original
convention
(which frankly was simpler) that the result (or comparison) is unsigned,
portably, regardless of word size. I suspect things will break if that is
changed,
although again using the C99 rule is probably less confusing in the end,
because both people and new incoming programs will expect the C99
interpretation.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-M9c8aea84ddf712920e17bc0e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Create HTML pages

[Charles Forsyth]

> I don't know whether pandoc runs
> on Plan 9.


It is Haskell, so I suspect not.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te71ff4b45d15900f-M78a822fd2c0d5283486b02f4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Charles Forsyth]

https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf might
be of interest.

They turned up at an embedded systems show at Birmingham NEC about that
time.
I was attending independently, but it was interesting to see,.
Wandering about some boring other stands, I found one that was showing off
a small embedded device running a remarkable system.
There was source code on the screen.
"Hmm", I asked, "what's the language it's running?"
Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on a
micro with a real-time garbage collector and in-service code updating on
the fly.
Just fantastic. We bemoaned the boring nature of most of the stands. I
mentioned Styx-on-a-Chip and he wandered off to have a look, returning to
say it was also interesting.
I forget the name of the system, but eventually the company was sold on or
got different investors in, who turned it into a Java thing. As usual.

On Fri, 28 Jan 2022 at 10:18, Lucio De Re  wrote:

> On 1/28/22, Bakul Shah  wrote:
> >
> > Think of really simple, low power, low cost devices.
> > USB can also provide power. USB+ATtiny85 devel boards
> > cost ~$3 even at Amazon. And FPGA boards can be
> > pretty inexpensive too. If you can find them.
> >
> I've recommended olimex.com in the past. They specialise in Open
> Architecture Hardware. Their prices are very reasonable and product
> range quite broad.
> 
> Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mc901f3049ed9f148d9ee00e7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Charles Forsyth]

I've been happy with the Microsoft Bluetooth Mobile Mouse 3600
bearing
in mind that I'm using 9vx on a Dell as my terminal.
I should probably see if it can be made to work on an rpi

On Fri, 28 Jan 2022 at 12:45, Steve Simon  wrote:

> I am a long term sam user and a three button mouse, but I also like the
> ease of navigation of a scroll wheel.
> 
> I use a Beatus mouse - three real buttons and a scroll wheel on the side
> for your thumb.
> Sadly they are only made right handed and they are a little small for my
> hand but they are still the best
> I have found.
> 
> Google will find them quite easily.
> 
> -Steve
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M73ba293845513288df73c465
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] How to generate a "debuggable" lex.yy.c?

[Charles Forsyth]

Perhaps add a copy of allprint, without the character counting, to replace
the existing extern declaration in your ncform, still #ifdef'd with
LEXDEBUG.
The signature of allprint should also be static void allprint(Uchar) and
the exotic initial lines of sub1.c's allprint can be removed.
It needs a #include  inside the #ifdef to get isprint.

Originally on Unix there was a separate little lex library with its own
version of allprint.

On Wed, 10 Nov 2021 at 19:28, gomfy via 9fans <9fans@9fans.net> wrote:

>
> Hello,
>
>
> I would like to generate a lexer with debug functionality. I'm relying on
> a slightly modified versions of the sources:
> https://9fans.github.io/plan9port/man/man3/bio.html
>
> https://9fans.github.io/plan9port/man/man1/yacc.html
>
> https://9fans.github.io/plan9port/man/man1/lex.html
>
>
>
> As far as I can tell, my issues are not related to the fact that I'm
> working with a slightly modified version, but I thought I'll mention it
> just to be on the safe side.
>
>
> The first issue was that the debug information collected in fdebug was
> not flushed and as a result the *y.debug* file for the lexer kept showing
> up empty. I had to add Bterm(fdebug); at the end of the main() in *yacc.c*
> to get the *y.debug* file to be generated with content.
>
>
> Now, my issue is that if I'm compiling the generated *lex.yy.c* with
> -DLEXDEBUG I get:
>
> undefined reference to `allprint(char)'
>
> because of sections like the one below:
>
>
>
> # ifdef LEXDEBUG
> if(debug){
> fprintf(yyout,"char ");
> allprint(yych);
> putchar('\n');
> }
> # endif
>
>
>
> The allprint() function is defined in the Lex source *sub1.c*.  It seems
> I'd have to link against the Lex source to be able to compile *lex.yy.c*
> in debug mode, which would be a bit complicated as there are some clashes
> with my other application. Other complications are caused by the global
> variables that show up in allprint() and other functions that are listed
> in the DEBUG section of *sub1.c*.
>
>
> Can someone point me in the right direction, or tell me what am I missing
> here?
>
>
>
> Thanks!
> Gyorgy
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdade85f2048629bd-Mb3af3d5e0cba2640853d9f74
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] v9fs vs mmap (not quite SOLVED)

[Charles Forsyth]

It's mildly amusing that a language that emphases explicit error returns
should discard a system interface that does that in favour of one that's
not even a raised exception but a trap.
(ok, ok, Unix typically just returns crappy EIO on a real error, but does
distinguish several other cases such as ENOSPC.)
And it's relying on the paging subsystem which is even worse.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M4aaa692507919c2a04fe1203
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] v9fs vs mmap (not quite SOLVED)

[Charles Forsyth]

I think the question is why mmap works over 9p from linux up to a point but
then fails in some context: what's the difference?

On Wed, 27 Oct 2021 at 00:47, Skip Tavakkolian 
wrote:

> I don't know if I'm helping or confusing things, but here's a bit more
> experimentation;
> I did the above, and git worked correctly with diod as the file server
> (=> git requires syscalls
> that 9p2000.l provides).  But compiling seems to run into an untested
> combinatorial case:
>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M8f97c3d5e84df8ac2ba5bd15
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Help with a sam cleanup script

[Charles Forsyth]

to avoid errors, perhaps something along the lines of

X g/$/v/$/a
this is a long block comment.
it has no effect.
.

X prevents ?no current file

there are probably even shorter variants

On Tue, Aug 3, 2021 at 5:31 PM  wrote:

> On Tuesday, 3 August 2021, at 6:29 PM, fwrm wrote:
>
> As for comments in scripts, if you use ssam(1) to run them the easiest way
> would be starting the lines you want to be ignored with a character that
> isn't a sam command (this will work because ssam sends stderr to /dev/null).
>
> I am very grateful to you for this. Thanks so much.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T10b1d559ae7d981e-Mc443cf253463a264c625ac19
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] A few questions about sam

[Charles Forsyth]

>
>
>- The sam tutorial speaks of sam being "downloaded". (*A tutorial for
>the sam language*.) I am not exactly sure what "downloaded" means in
>this context.
>
> sam originally ran on a terminal that had its own little operating system
and applications could be downloaded into each terminal window.
sam ran in two parts: sam on the host and samterm (downloaded) on the
terminal. they communicate using a unique protocol.
Here's a video about the original Blit terminal and how that works:
https://www.youtube.com/watch?v=emh22gT5e9k
(The original editor on the Blit was jim.)
sam is described in detail in a paper:
https://docs.google.com/viewer?url=https%3A%2F%2F9p.io%2Fsys%2Fdoc%2Fsam%2Fsam.pdf

Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T60b5c1929a63b077-M20b73a1d7ea627a04a463cef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] A few questions about sam

[Charles Forsyth]

>/tmp/x: ?warning: last char not newline

is a warning you get when you try to write a file that doesn't end with a
newline, the other message:

> I sometimes get the "?newline expected" error,

is provoked by a syntax error in a command in the sam (command) window. For
instance, try typing
   qx
(and a newline)
it expects nl after q

On Thu, Jul 22, 2021 at 8:14 PM mcz  wrote:

> >  * Must every sam file end with a newline? I.e. even files with simple
> text?
>
> No, I don't think sam cares.
>
> > I sometimes get the "?newline expected" error,
>
> In sam version I use, it's just a warning. The file is saved without
> newline at
> the end, unless I add it there.
>
> > which I would like to avoid if possible.
> 
> The best way to avoid the warning about the missing newline character is
> to add
> the missing newline character.
> 
> Some programs (POSIX world, ANSI C) assume that every line ends with
> newline
> character, so most editors add it for you if it's missing. Sam apparently
> thinks it's good to have it, but doesn't get in your way if you don't add
> it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T60b5c1929a63b077-Mee00a57a34c332edd0a4e2a0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] non-interruptible temporary: why do we care?

[Charles Forsyth]

yes, I'm not sure why it doesn't do that, but probably if I try to add that
code I'll soon find out!

On Wed, Jun 16, 2021 at 9:29 PM  wrote:

> Quoth un...@cpan.org:
> > Quoth o...@eigenstate.org:
> > > Our compilers will sometimes produce a warning about
> > > a non-interruptible temporary:
> > > ...
> > > Why do we warn about non-interruptible
> > > temporaries? What issues am I missing?
> >
> > Silence to this question means no one knows, right?
> >
> 
> I pinged Charles off list and got a response -- it means
> we're falling into the rathole; in other words, we're
> accessing a global variable.
> 
> The right thing to do (IMO) is make the compiler allocate
> on the stack, and then the warning would be unneded.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdcfb8f84c90eb199-M8efb875683ddcb305946ecdd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 1st and 2nd edition ISOs at p9f.org/dl are defective

[Charles Forsyth]

The 8+3 restriction is related to that. As often now, Wikipedia supplies
more detail. Apparently High Sierra was the basis for the original format,
not an extension: I was of course confusing it with Rock Ridge.

On Mon, May 24, 2021 at 11:26 PM Charles Forsyth 
wrote:

> I don't know the answer to the following question, which is why I ask it:
> does that happen if you use 9660srv
> under Plan 9 (-ish) to access those images? (Perhaps you already are, but
> it would still be useful to know.)
> It's quite a long time ago, but as I recall early CD formats took a
> literal view of permissions: "I'm on a read-only medium,
> otherwise you'd be using the later and probably incompatible standard for
> RW optical, so all my file system permissions are "read".
> Later people took advantage of having umptieen parallel trees in there in
> different formats (Joliet for MS, High Sierra for UNIX-ish)
> and Plan 9 added its own. I think those early CDs relied on that. Later
> ones added parallel structures in both Joliet and High Sierra
> format so you could get more accurate meta-date out of the CDs when
> mounted on Windows or SunOS.
>
>
> On Mon, May 24, 2021 at 10:46 PM Anonymous AWK fan via 9fans <
> 9fans@9fans.net> wrote:
>
>> All file names are lower case (this makes some files inaccessible,
>> because there are sometimes multiple files with the same name) and the
>> modes, owners and groups are all --r--r--r-- (d-r-xr-xr-x for
>> directories), cdrom and iso, respectively.
>> 
>> Anonymous AWK fan
>> 
>> --
>> Mailfence.com
>> Private and secure email

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5f0b8bf3259974e3-M1aae943baab476d407c3dab5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 1st and 2nd edition ISOs at p9f.org/dl are defective

[Charles Forsyth]

I don't know the answer to the following question, which is why I ask it:
does that happen if you use 9660srv
under Plan 9 (-ish) to access those images? (Perhaps you already are, but
it would still be useful to know.)
It's quite a long time ago, but as I recall early CD formats took a literal
view of permissions: "I'm on a read-only medium,
otherwise you'd be using the later and probably incompatible standard for
RW optical, so all my file system permissions are "read".
Later people took advantage of having umptieen parallel trees in there in
different formats (Joliet for MS, High Sierra for UNIX-ish)
and Plan 9 added its own. I think those early CDs relied on that. Later
ones added parallel structures in both Joliet and High Sierra
format so you could get more accurate meta-date out of the CDs when mounted
on Windows or SunOS.


On Mon, May 24, 2021 at 10:46 PM Anonymous AWK fan via 9fans <
9fans@9fans.net> wrote:

> All file names are lower case (this makes some files inaccessible,
> because there are sometimes multiple files with the same name) and the
> modes, owners and groups are all --r--r--r-- (d-r-xr-xr-x for
> directories), cdrom and iso, respectively.
> 
> Anonymous AWK fan
> 
> --
> Mailfence.com
> Private and secure email

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5f0b8bf3259974e3-M5278d8287de161701114ae08
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troff refer and bib

[Charles Forsyth]

> I personally found the code hard to read,


The original looked like this:

tabs (sv, line)
char *sv[], *line;
{
char *p;
int n 0;
sv[n++] = line;
for( p= line; *p; p++)
{
if (*p == '\n')
{
*p=0;
sv[n++] = p+1;
}
}
return(n-1);
}
class (nt, tv)
char *tv[];
{
if (hastype (nt, tv, 'J'))
return("1 journal-article");
if (hastype (nt, tv, 'B'))
return("3 article-in-book");
if (hastype (nt, tv, 'R'))
return ("4 tech-report");
if (hastype (nt, tv, 'G'))
return ("4 tech-report");
if (hastype (nt, tv, 'I'))
return("2 book");
if (hastype (nt, tv,'M'))
return ("5 bell-tm");
return("0 other");
}

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e70e97724f65028-M256992115658f974c595849a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troff refer and bib

[Charles Forsyth]

I still use it. I think it differs in many ways from the original version
(the Caldera licence was to allow the 7th Edition code to be used in 2002).
Not least that it's formatted and arranged to be readable. It made some
things dynamic so it could handle large reference libraries.
There were bug fixes.
I also replaced the original's internal fgrep implementation by the
Aho-Corasick as developed in the paper.

On Thu, Apr 8, 2021 at 12:28 PM sirjofri 
wrote:

>
> 08.04.2021 12:57:15 Maurizio Boriani :
> >   is there somewhere in plan9 code base (9front, plan9port etc...) the
> > source code of refer and/or bib? I found many references to 'em but
> > didn't found the code or programs.
> 
> I got mine from contrib:
> 
> https://9p.io/wiki/plan9/contrib_index/index.html
> (EXTRA section, by charles forsyth)
> 
> sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e70e97724f65028-M56c244cf2509e8b0a3e5dbb9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Can compile Plan9 C compiler for windows10?

[Charles Forsyth]

>
> I doubt very much that using the Plan 9 C compilers will bring much
> additional benefit for finding bugs (except bugs in the compiler!).


The cross-file type-checking does sometimes pick up unpleasantness caused
by type mismatches.
It was originally added to allow dynamically-loaded object modules to be
checked against the loading specification.
It has found a few problems elsewhere, including one in Python where one .c
file included a .h with a certain #define
in scope that another .c file didn't define by accident, causing the two .c
files to have completely different memory layouts
for a structure.


> Out of curiousity, why is linking against the system libraries so
> hard?  I assume a port of kenc to Linux would have a driver program
> that would just invoke the system ld(1).  I'd think that getting
> the ABI and generation of ELF (or of standard Linux assembly language)
> correct would be the hard part.
> What am I missing?


It works very differently from what you expect
http://9p.io/sys/doc/compiler.html  :

The compiler is a single program that produces an object file. Combined in
the compiler are the traditional roles of preprocessor, lexical analyzer,
parser, code generator, local optimizer, and first half of the assembler.
The object files are binary forms of assembly language, similar to what
might be passed between the first and second passes of an assembler.

Object files and libraries are combined by a loader program to produce the
executable binary. The loader combines the roles of second half of the
assembler, global optimizer, and loader.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-Mae8386c3c15f3973027b8de6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] problem with installing plan9 from USB disk image

[Charles Forsyth]

That reminds me that this
https://retrage.github.io/2020/08/01/9pfspkg-en.html looked quite
interesting but I haven't had a chance to try it yet.

On Fri, Mar 26, 2021 at 3:20 PM Charles Forsyth 
wrote:

> I see that 9front has had some UEFI boot support for 6 years.
> I use an earlier version of their iplpxe on my 64-bit cpu servers (not
> booting 9front).
> I did use the iplfat and ipliso as well to boot other kernels.
> When I've got a moment I might diff to see what changes I made.
>
> On Fri, Mar 26, 2021 at 3:08 PM Richard Miller <9f...@hamnavoe.com> wrote:
>
>> >  1. Dual booting is not possible
>> >  2. UEFI introduced vulnerabilities ...
>> 
>> Don't these two things cancel each other out? Can we not use
>> the same vulnerabilities to induce the firmware to boot our
>> own choice of operating system? It wouldn't be the first time
>> Plan 9 was installed using ... shall we say unofficial methods?
>> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-M4773c5f1d46810c88aa46837
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] problem with installing plan9 from USB disk image

[Charles Forsyth]

I see that 9front has had some UEFI boot support for 6 years.
I use an earlier version of their iplpxe on my 64-bit cpu servers (not
booting 9front).
I did use the iplfat and ipliso as well to boot other kernels.
When I've got a moment I might diff to see what changes I made.

On Fri, Mar 26, 2021 at 3:08 PM Richard Miller <9f...@hamnavoe.com> wrote:

> >  1. Dual booting is not possible
> >  2. UEFI introduced vulnerabilities ...
> 
> Don't these two things cancel each other out? Can we not use
> the same vulnerabilities to induce the firmware to boot our
> own choice of operating system? It wouldn't be the first time
> Plan 9 was installed using ... shall we say unofficial methods?
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-M262ceaffeb17d280215d6454
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] how to extract an .iso file using Inferno

[Charles Forsyth]

9660srv is the command you need from the Inferno dossrv(4) page.

On Fri, Mar 26, 2021 at 10:11 AM Ethan Gardener  wrote:

> On Fri, Mar 26, 2021, at 9:56 AM, saif.re...@outlook.com  saif.resun%40outlook.com> wrote:
> > hello there!
> >
> > I want to extract an .iso file of plan9 operating system in Inferno
> system. Is there any command to do so?
> % lookman cd-rom
> man 4 dossrv # dossrv(4)
> 
> It's not actual extraction, but you can read & copy the files.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T00cb03faebe93c91-M4e40844f92a59c39cdb1d913
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2c/2l make sense, but why 1c/1l?

[Charles Forsyth]

To be fair, I probably should convert my machine with lots of disks with
lots of historical partitions into a single tree with the contents just as
subdirectories.
It's not as though anyone's going to use them as images ever again. They
only ended up that way because the originals were in strange formats on
increasingly dodgy devices, and it was easier just to copy the partitions
across to partitions of newer bigger drives.

As an aside, it still amuses me that VN's worm jukebox would now fit on an
SD card that I could easily lose.

On Wed, Feb 24, 2021 at 11:26 PM Charles Forsyth 
wrote:

> I think they might have been there for some other reason and then was used
> for Inferno, which they somewhat had going on a Palm Pilot in some form
> (not necessarily as the native kernel).
> If I waded through a ton of archive material I could probably find the
> latter, to see what it was, but I'm not sure it's really worthwhile now.
>
> On Wed, Feb 24, 2021 at 8:16 PM Joseph Stewart 
> wrote:
>
>> Charles could probably answer this better than me, but weren't the 68k
>> compilers made to support Inferno?
>> -joe
>>
>> On Mon, Feb 22, 2021 at 11:18 PM  wrote:
>> >
>> > Hello,
>> >
>> > I'm wondering about the history of the 68000 compiler/tools.  Support
>> for the 68020 makes sense, it had an MMU, but 68000 did not.  And it had
>> some design flaws that prevented it from working correctly with the
>> external MMU, the 68451.  So why does/did Plan 9 have a 68000 compiler?
>> Did Plan 9 ever run on an MMU-less 68000?
>> >
>> > thx.
>> > 9fans / 9fans / see discussions + participants + delivery options
>> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf34475f1bb69674a-Mf5d48b33b42aa6f6e483a745
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2c/2l make sense, but why 1c/1l?

[Charles Forsyth]

I think they might have been there for some other reason and then was used
for Inferno, which they somewhat had going on a Palm Pilot in some form
(not necessarily as the native kernel).
If I waded through a ton of archive material I could probably find the
latter, to see what it was, but I'm not sure it's really worthwhile now.

On Wed, Feb 24, 2021 at 8:16 PM Joseph Stewart 
wrote:

> Charles could probably answer this better than me, but weren't the 68k
> compilers made to support Inferno?
> -joe
>
> On Mon, Feb 22, 2021 at 11:18 PM  wrote:
> >
> > Hello,
> >
> > I'm wondering about the history of the 68000 compiler/tools.  Support
> for the 68020 makes sense, it had an MMU, but 68000 did not.  And it had
> some design flaws that prevented it from working correctly with the
> external MMU, the 68451.  So why does/did Plan 9 have a 68000 compiler?
> Did Plan 9 ever run on an MMU-less 68000?
> >
> > thx.
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf34475f1bb69674a-M0d6f8b10f10462355ff6de16
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Charles Forsyth]

It's more interesting that one is immediate by inspection. But why?

On Mon, Feb 22, 2021 at 11:10 PM Bakul Shah  wrote:

> Spinellis has put together a browsable repo based on various source
> distributions
> which I find useful. I keep a local copy as it is under 2GB. All I had to
> do was
>
> git log | less -ip "ross harvey"
>
> Michael Cain's version on sigapl.org site seems to be a different fork.
> Also worked
> over quite a bit.
>
> On Feb 22, 2021, at 2:43 PM, Charles Forsyth 
> wrote:
>
> It's amusing that the github has "42 years ago".
>
> You can tell instantly that the line
> if (TERMtype == 0)c = (int)*iline++;
> wasn't written by Thompson.
>
> On Mon, Feb 22, 2021 at 10:02 PM Bakul Shah  wrote:
>
>> On Feb 22, 2021, at 10:28 AM, tlaro...@polynum.com wrote:
>> >
>> > There are various versions of an APL interpreter and, amongst these,
>> > a version by Ken Thompson, Ross Harvey, Douglas Lanam.
>> 
>> This can be found in Diomidis Spinellis' unix history repo @
>> 
>> https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl
>> 
>> Synthesized from 3bsd, which you can find it here:
>> 
>> https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M281c649ebf07b0d790f318f5>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Ma78673da48df4053820043fa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Charles Forsyth]

It's amusing that the github has "42 years ago".

You can tell instantly that the line
if (TERMtype == 0)c = (int)*iline++;
wasn't written by Thompson.

On Mon, Feb 22, 2021 at 10:02 PM Bakul Shah  wrote:

> On Feb 22, 2021, at 10:28 AM, tlaro...@polynum.com wrote:
> >
> > There are various versions of an APL interpreter and, amongst these,
> > a version by Ken Thompson, Ross Harvey, Douglas Lanam.
> 
> This can be found in Diomidis Spinellis' unix history repo @
> 
> https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl
> 
> Synthesized from 3bsd, which you can find it here:
> 
> https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Mae4997e3e15481dbbab01024
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Charles Forsyth]

I'm fairly sure Thompson wrote it on sabbatical in Berkeley. I think he
also wrote the first version of a Pascal compiler.
Pascal isn't a difficult language but I remember that compiler having an
unusual style. I think others reworked it significantly later,
so if it's there at all it's worth looking at the earliest possible one.

On Mon, Feb 22, 2021 at 8:37 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <
lyn...@orthanc.ca> wrote:

> tlaro...@polynum.com writes:
>
> > There are various versions of an APL interpreter and, amongst these,
> > a version by Ken Thompson, Ross Harvey, Douglas Lanam.
> >
> > Is that this one you are looking for?
> 
> That sounds like the one.  It's entirely possible the version I
> started with came from one of the BSD tapes (we were source
> licensed so we had the full set of tapes from V6 onwards).
> 
> I have the CSRG CD set, but it's in a box in a storage locker
> right now.  Is there any chance you could pull the above APL
> source files and leave them someplace I could grab them from?
> (9p.io would work fine.)
> 
> Thanks!
> 
> --lyndon

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M1d37bce19d6151f033b72125
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[Charles Forsyth]

I found several of Bryan Ford's ideas interesting as always here,
particularly Structured Streams (https://bford.info/pub/net/sst-abs/) and
Breaking Up the Transport Logjam (https://bford.info/pub/net/logjam-abs/)

On Wed, Jan 27, 2021 at 4:53 PM  wrote:

> Quoth David Arroyo :
> > On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote:
> > > It's well-known that 9P has trouble transferring large files (high
> > > volume/high bandwith) over high-latency networks, such as the Internet.
> >
> > From what I know of 9P, I don't think this is the fault of the protocol
> > itself. In fact, since 9P lets the clients choose Fid and Tag
> identifiers,
> > it should be uniquely well suited for "long fat pipes". You could avoid
> > waiting for round-trips by optimistically assuming your requests succeed.
> > For example, you could do the following to optimistically read the first
> > 8K bytes of a file without needing to wait for a response from the
> server.
> >
> > * Twalk tag=1 fid=0 newfid=1 /path/to/somefile
> > * Topen tag=2 fid=1 o_read
> > * Tread tag=3 fid=1 off=0 count=4096
> > * Tread tag=4 fid=1 off=4096 count=4096
> > * Tclunk tag=5 fid=1
> >
> > I'm not aware of any client implementations that do this kind of
> > pipelining, though.
> >
> > David
> 
> This also has some hairy edge cases. For example,
> what happens to the actions in the pipeline if one
> of the operations fails?
> 
> I think that for this kind of pipelining to be
> effective, 9p may need some notion of 'bundles',
> where the first failure, short write, or other
> exceptional operation would cause all other
> commands in the bundle to be ignored.
> 
> Another issue is that its' difficult to retrofit
> this pipelining into the plan 9 system call
> interface; when do you return an error from
> read(2)? what if there are mutiple Treads?
> 
> Finally, there's the problem of flow control;
> with 9p, round trip time limits starvation,
> at least to a degree. But how do you handle
> congestion if you can stuff as many 9p packets
> down a single connection as possible? There's
> no packet loss, but you can end up with very
> long delays as small reads like /dev/mouse
> get queued behind bulk transfers.
> 
> There are some programs that try to handle this
> for 'well behaved' file systems (eg, fcp(1),
> or http://src.a-b.xyz/clone/, but making it
> happen in general is not trivial.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M40bb94bd40d97df72c885f69
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] authoritative source for u9fs?

[Charles Forsyth]

Yes but bitbucket ditched hg so its now all git


On Mon, Jan 25, 2021 at 12:10 AM Lyndon Nerenberg  wrote:

> Charles Forsyth writes:
>
> > it's also on bitbucket not github mainly for historical reasons but I
> also
> > can never decide which I dislike more.
> :-)
>
> The nice thing about having it in hg is that mercurial is part of
> 9front, so there's no need to muck about getting git installed.
>
> --lyndon
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-Mf163251a751866fcf764cc32
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] authoritative source for u9fs?

[Charles Forsyth]

it's also on bitbucket not github mainly for historical reasons but I also
can never decide which I dislike more.
Originally, it was on Google Source and bitbucket had hg, so I used that.
Now that they are all gits, perhaps there's no difference.
At one time I thought that Atlassian did say they backed it up,
which Github suggested wasn't needed because of the remote archives, but
that might be outdated.

On Sun, Jan 24, 2021 at 11:30 PM Charles Forsyth 
wrote:

> I've just accepted an important pull request to it that I missed, until I
> looked at it in response to this, so you should do another pull to get that.
> Generally, though it has been reasonably stable for some time. Changes are
> often just to cope with this year's #ifdefs or feature defines.
>
>
> On Fri, Jan 22, 2021 at 9:17 AM Dworkin Muller 
> wrote:
>
>> On Fri, 22 Jan 2021 03:20:03 -0500, Fazlul Shahriar 
>> wrote:
>> fshahriar> https://bitbucket.org/plan9-from-bell-labs/u9fs/src/master/
>> 
>> That looks much more believable than the others.  Thank you very much
>> for the pointer.
>> 
>> Dworkin

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-M0fd0a9e2ffb13d78e01af2c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] authoritative source for u9fs?

[Charles Forsyth]

I've just accepted an important pull request to it that I missed, until I
looked at it in response to this, so you should do another pull to get that.
Generally, though it has been reasonably stable for some time. Changes are
often just to cope with this year's #ifdefs or feature defines.


On Fri, Jan 22, 2021 at 9:17 AM Dworkin Muller 
wrote:

> On Fri, 22 Jan 2021 03:20:03 -0500, Fazlul Shahriar 
> wrote:
> fshahriar> https://bitbucket.org/plan9-from-bell-labs/u9fs/src/master/
> 
> That looks much more believable than the others.  Thank you very much
> for the pointer.
> 
> Dworkin

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-M74684f2bf32f35f0b7c76a2d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Charles Forsyth]

That's a good question. utils/tl is the 5l I've referred to, which can do
ARM32 and Thumb interlinking. utils/5l is now fitfully
aligned (back-and-forth) with Plan9's 5l,
that couldn't do the interlinking.

On Sat, Nov 7, 2020 at 9:24 PM Anthony Martin  wrote:

> While we're asking questions, how does utils/tl differ from utils/5l?
> 
> Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M720793ab8b79b6df543d3c96
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Charles Forsyth]

A slight correction (I made it earlier but didn't highlight it): 5a is also
used for Thumb code, as "5a -t" to restrict the input to thumb
constructions and tag the output as Thumb code (using .t files instead of
.5)
The thumb mkfile sets AS=5a -t
Since the Thumb-2 changes aren't supported, and it's the original Thumb, I
think that makes the supported architecture Armv6-M in current
documentation terms.
It looks to me as though it would work on Cortex M0, but I think the thumb
mode was only ever used by us on ARM's little Armv7-t Evaluator board,
which I can't even find documented now.
Normally even that board ran in (normal) ARM32 mode. The Thumb work on it
was just a stepping stone for using Thumb mode on a proprietary 3rd party
ARM implementation, although even there it was probably experimental.
Inferno can run without an MMU. Even given an MMU it sets a fairly flat map
across physical memory and the MMU functionality is mainly used to map
devices.
The os/ks32 directory is a guide to squashing the system down to fit modest
if not tiny memory (again, in ARM32 mode).

On Sat, Nov 7, 2020 at 2:24 PM Thaddeus Woskowiak 
wrote:

> On Thu, Nov 5, 2020 at 7:12 PM Charles Forsyth
>  wrote:
> >
> > There was a 5[ac] variant for Inferno (ta, tc) that produced Thumb code,
> and 5l could link Thumb and ARM32 code.
> > That wasn't extended once Thumb-2 was issued, since it was different
> enough to require a fair amount of work and we had no immediate application
> on the Cortex.
> >
> >
> > On Thu, Nov 5, 2020 at 11:38 PM Thaddeus Woskowiak <
> tswoskow...@gmail.com> wrote:
> >>
> >> I would like to know if anyone is working on or exists an Arm Thumb
> >> compiler so one could use plan 9 to program Arm Cortex M0/3/4/7
> >> microcontrollers directly. I know of Charles Forsyth's xc AVR compiler
> >> which is also interesting. Though I have yet to try it out.
> >>
> >> -taw
> >
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink
> 
> Charles, Thank you for the information. So Thumb compiling and
> assembly is handled by tc and ta respectively while 5l can handle
> linking both thumb code and arm 32.
> 
> I guess my next question is: does this mean Inferno can run on certain
> Cortex-M micros since it can run MMU-less? (provided enough memory of
> course) And has this been done before?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M17cdefbb28d2693788d7a348
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Charles Forsyth]

http://vitanuova.com/inferno/downloads.html

On Fri, Nov 6, 2020 at 12:51 AM Don A. Bailey  wrote:

> Where the heck is the inferno tree?
>
> On Nov 5, 2020, at 6:48 PM, Charles Forsyth 
> wrote:
>
> 
> tc is different because the register allocation and code generation
> strategies are different from normal ARM
>
> On Fri, Nov 6, 2020 at 12:46 AM Charles Forsyth 
> wrote:
>
>> It's utils/tc in the Inferno tree. 5a does both ARM32 and Thumb (because
>> it's abstract assembly), as does 5l.
>>
>> On Fri, Nov 6, 2020 at 12:28 AM Don A. Bailey 
>> wrote:
>>
>>> Any source available?
>>>
>>> On Nov 5, 2020, at 6:11 PM, Charles Forsyth 
>>> wrote:
>>>
>>> 
>>> There was a 5[ac] variant for Inferno (ta, tc) that produced Thumb code,
>>> and 5l could link Thumb and ARM32 code.
>>> That wasn't extended once Thumb-2 was issued, since it was
>>> different enough to require a fair amount of work and we had no
>>> immediate application on the Cortex.
>>>
>>>
>>> On Thu, Nov 5, 2020 at 11:38 PM Thaddeus Woskowiak <
>>> tswoskow...@gmail.com> wrote:
>>>
>>>> I would like to know if anyone is working on or exists an Arm Thumb
>>>> compiler so one could use plan 9 to program Arm Cortex M0/3/4/7
>>>> microcontrollers directly. I know of Charles Forsyth's xc AVR compiler
>>>> which is also interesting. Though I have yet to try it out.
>>>> 
>>>> -taw
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M19ec8971e0a6bf813470bdd5>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-Mfa4b52ef1d71dc9e3bb95d97
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Charles Forsyth]

tc is different because the register allocation and code generation
strategies are different from normal ARM

On Fri, Nov 6, 2020 at 12:46 AM Charles Forsyth 
wrote:

> It's utils/tc in the Inferno tree. 5a does both ARM32 and Thumb (because
> it's abstract assembly), as does 5l.
>
> On Fri, Nov 6, 2020 at 12:28 AM Don A. Bailey 
> wrote:
>
>> Any source available?
>>
>> On Nov 5, 2020, at 6:11 PM, Charles Forsyth 
>> wrote:
>>
>> 
>> There was a 5[ac] variant for Inferno (ta, tc) that produced Thumb code,
>> and 5l could link Thumb and ARM32 code.
>> That wasn't extended once Thumb-2 was issued, since it was
>> different enough to require a fair amount of work and we had no
>> immediate application on the Cortex.
>>
>>
>> On Thu, Nov 5, 2020 at 11:38 PM Thaddeus Woskowiak 
>> wrote:
>>
>>> I would like to know if anyone is working on or exists an Arm Thumb
>>> compiler so one could use plan 9 to program Arm Cortex M0/3/4/7
>>> microcontrollers directly. I know of Charles Forsyth's xc AVR compiler
>>> which is also interesting. Though I have yet to try it out.
>>> 
>>> -taw
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M9c7a0aed3d67c936891acdd7>
>>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M518ed60981c86da7547bb995
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Charles Forsyth]

It's utils/tc in the Inferno tree. 5a does both ARM32 and Thumb (because
it's abstract assembly), as does 5l.

On Fri, Nov 6, 2020 at 12:28 AM Don A. Bailey  wrote:

> Any source available?
>
> On Nov 5, 2020, at 6:11 PM, Charles Forsyth 
> wrote:
>
> 
> There was a 5[ac] variant for Inferno (ta, tc) that produced Thumb code,
> and 5l could link Thumb and ARM32 code.
> That wasn't extended once Thumb-2 was issued, since it was
> different enough to require a fair amount of work and we had no
> immediate application on the Cortex.
>
>
> On Thu, Nov 5, 2020 at 11:38 PM Thaddeus Woskowiak 
> wrote:
>
>> I would like to know if anyone is working on or exists an Arm Thumb
>> compiler so one could use plan 9 to program Arm Cortex M0/3/4/7
>> microcontrollers directly. I know of Charles Forsyth's xc AVR compiler
>> which is also interesting. Though I have yet to try it out.
>> 
>> -taw
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M9c7a0aed3d67c936891acdd7>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-Mf59766f0b50a11670b261c9f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Charles Forsyth]

There was a 5[ac] variant for Inferno (ta, tc) that produced Thumb code,
and 5l could link Thumb and ARM32 code.
That wasn't extended once Thumb-2 was issued, since it was different enough
to require a fair amount of work and we had no immediate application on the
Cortex.


On Thu, Nov 5, 2020 at 11:38 PM Thaddeus Woskowiak 
wrote:

> I would like to know if anyone is working on or exists an Arm Thumb
> compiler so one could use plan 9 to program Arm Cortex M0/3/4/7
> microcontrollers directly. I know of Charles Forsyth's xc AVR compiler
> which is also interesting. Though I have yet to try it out.
> 
> -taw

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-Mbbaaac4b855169a43db7eb30
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Stockholm

[Charles Forsyth]

I'm escaping the UK's "We're lockdown crazy, lockdown mad!" for a few days
in November

On Sun, 25 Oct 2020, 01:21 Jeff Sickel,  wrote:

> Is that a syndrome a doctor could fix?
>
> > On Oct 24, 2020, at 5:49 PM, Charles Forsyth 
> wrote:
> >
> > Any 9fans in Stockholm?
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Taac80b468a3bf0fa-M77b6eb9af51a2d288142b6ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Stockholm

[Charles Forsyth]

Any 9fans in Stockholm?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Taac80b468a3bf0fa-M3b3bd2a78152fbe89807fdc0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Flakey DNS server

[Charles Forsyth]

It's a virtual city in Switzerland, which is famously neutral (hence Geneva
as location for various international organisations, and indeed as a
setting for several TV series)

On Sat, Oct 24, 2020 at 11:23 PM  wrote:

> Wes Kussmaul  writes:
>
> > On 10/7/20 12:08 AM, Lucio De Re wrote:
> >> my situation is getting
> >> more difficult as norms on the Internet are being bent by service
> >> provider that care for their profitability much more than for
> >> interoperation
> >
> > I suggest taking a look at https://www.osmio.ch/
> 
> I don't get it.  That Web site appears to be the municipal homepage for
> a city in Switzerland that uses digital certificates as official
> government-recognized ID.  What does that have to do with anything?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4e8db4c94a81d90f-M99ae9635befa9785b4527671
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9P Network Boot and Proxy Boot

[Charles Forsyth]

That is not at all off-topic. Thanks!

On Tue, Aug 4, 2020 at 1:16 PM Akira Moroo  wrote:

> Hello folks,
> 
> I show you 9pfsPkg, my 9P client file system for UEFI. Thanks to the
> network-transparency of 9P, it can boot any non-network-aware boot
> images without any modification. The source code is available at:
> 
> * https://github.com/yabits/9pfsPkg
> 
> As an application of the flexibility of 9P Boot, I also propose Proxy
> Boot, booting from another remote file system via the 9P server. By
> using this, we can do network boot from cloud storage (e.g. Google Cloud
> Storage using gcsfuse).
> 
> Please see my blog post for more details.
> 
> * https://retrage.github.io/2020/08/01/9pfspkg-en.html
> 
> I'm afraid of posting off-topic to the mailing list, but I would like to
> say thank you to all Plan 9 developers for making 9P.
> 
> --
> Akira Moroo

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tea2a5c86eeb3d71f-Mb2af52d29966ec2da193700b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Jim McKie

[Charles Forsyth]

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-_8MHiCUdeKOxzLBEI6VGHsSn4aTjdk

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td73b359f9dc68c15-M46c8ec7e96af870783ec060d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Charles Forsyth]

I see I'd misapplied the rule in walk(5) so fossil is fine. It has to do
with searching from . when you are there, which makes sense, not when
entering the directory from its parent,
so ignore that part of my earlier post.


On Mon, Jun 8, 2020 at 3:13 AM Charles Forsyth 
wrote:

> "search" is exactly the wrong word for what this bit does, because if you
>> don't have "search" permission, the one thing you can still do is look at
>> the names.
>
>
> in ramfs, but that's a bug that no-one had noticed
>
> On Mon, Jun 8, 2020 at 3:05 AM  wrote:
>
>> >>> So, cd'ing into a directory withut +x leads
>> >>> to an inescapabler trap.
>> >> ...
>> >> fossil just moved up another notch in my estimation because directory
>> search restriction is so broken.
>> >
>> > o...@eigenstate.org, what version of fossil were your experiments done
>> on?
>> > My observations are different:
>> >
>> > term% mkdir -p d/a/b
>> > term% touch d/x
>> > term% chmod -x d
>> > term% ls -ld d
>> > d-rw-r--r-- M 12 miller miller 0 Jun  7 16:38 d
>> > term% cd d
>> > term% cd ..
>> > term% ls d
>> > d/a
>> > d/x
>> > term%
>> >
>> > No trap that I can see here.
>> 
>> cwfs, but -- yeah, it's enforced inconsistently across
>> different file systems. (of course).
>> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M39749150e29409f155014124
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Charles Forsyth]

>
> "search" is exactly the wrong word for what this bit does, because if you
> don't have "search" permission, the one thing you can still do is look at
> the names.


in ramfs, but that's a bug that no-one had noticed

On Mon, Jun 8, 2020 at 3:05 AM  wrote:

> >>> So, cd'ing into a directory withut +x leads
> >>> to an inescapabler trap.
> >> ...
> >> fossil just moved up another notch in my estimation because directory
> search restriction is so broken.
> >
> > o...@eigenstate.org, what version of fossil were your experiments done
> on?
> > My observations are different:
> >
> > term% mkdir -p d/a/b
> > term% touch d/x
> > term% chmod -x d
> > term% ls -ld d
> > d-rw-r--r-- M 12 miller miller 0 Jun  7 16:38 d
> > term% cd d
> > term% cd ..
> > term% ls d
> > d/a
> > d/x
> > term%
> >
> > No trap that I can see here.
> 
> cwfs, but -- yeah, it's enforced inconsistently across
> different file systems. (of course).
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M8e0db3a8ea1ca83dc1cd64b9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Charles Forsyth]

execute permission on files, meaning here non-directories, is a special
variant of read. a file with mode 0111 can be opened with OEXEC and read(2)
will work as well as exec(2),
but can't be opened with OREAD, because it's not got any of 0444 set. bits
0111 distinguish a file with contents that are intended to be executed once
read from files with only 0444 that do not contain executable content.
you wouldn't want every readable file to be executable (especially if
you've used systems that didn't have that distinction).
on the other hand, in a distributed file system, the client needs the
contents of the file to run it (whether code or #!script) so it needs to be
able to read files with just OEXEC.
I suppose the rule could have been that it would need mode 5 (r+x) to make
clear that the file was also readable, but it isn't.

that OEXEC allows reading isn't true for a directory because exec means
"search", so if it's mode 0111 (say) you can chdir into it but not read the
names within it.
if you know a name of a file in that directory, though, you can still open
that. that's entirely enforced by the server.

as the bug in access(2) suggests, only the server knows whether access
should be granted, and the open call gets it to do that,
but it doesn't work for OEXEC for directories as others have noted. perhaps
stat+chdir is the most accurate test, since you need x (search) permission
to walk(5) into a directory,
but the caller won't thank you for the chdir (and there's no easy or
certain way back), and ... that restriction isn't enforced by fossil or
ramfs. (ramfs wrongly allows you to read a directory that's mode 0.)

probably the best thing is just to ignore the owner/group/other
distinction, and if the open(...OEXEC) fails, dirstat it, and if it's a
directory with any of 0111 set, it's fine (a little better than now).



On Sat, Jun 6, 2020 at 7:38 AM Ethan Gardener  wrote:

> On Fri, Jun 5, 2020, at 8:22 PM, Richard Miller wrote:
> > Looks to me like access(2) is not doing the right thing for directory
> > execute (=search) permission.
> 
> thanks for the tip. access is a very simple function. it doesn't do the
> right thing, but there's a reason:
> 
> BUGS
>  Since file permissions are checked by the server and group
>  information is not known to the client, access must open the
>  file to check permissions.  (It calls stat(2) to check sim-
>  ple existence.)
> 
> it's open() which is failing. i suppose it should.
> 
> if the open fails, maybe access should stat the file, and if it's a
> directory, try dirread(2). or maybe just opening it for reading will work.
> i don't know, i'm new to this bit of plan 9 & i haven't slept.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M873b037de0ec96e4b493d3d7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Firewall/NAT and importing outside interface

[Charles Forsyth]

>
> If one is running a mail server and has it inside their firewall and if
> using one IP then t has to use NAT. Couldn't one presumeably use the setup
> above and run a mail server on Plan 9 and bypass having to use NAT?  And
> also do the same thing for a web server?


Yes, I do that. The example you quoted creates two independent IP stacks,
starting with the default '#I0' IP stack on ether0, then adding a new IP
stack '#I1' connected to ether1 (#l1).
There is a separate TCP/IP, UDP/IP, ICMP etc for each stack. I also import
/net from a Linux server via Inferno (on Linux) so I can send mail from a
non-RBLd address.
You can create several types of virtual interface ("medium") on the IP
stack, connected to a user-mode process. See pkg and netdev in ip(3)

  I still have a router with NAT though for non-Plan 9 machines. I never
got round to writing a NAT for Plan 9 (which could work in user mode).

On Fri, May 8, 2020 at 7:55 PM Robert Sherwood 
wrote:

> I love the idea of importing the external interface to get outside the
> network. When I first read about this in Plan9, that's when the system
> really "clicked" for me.
>
> On Fri, May 8, 2020 at 1:08 PM hiro <23h...@gmail.com> wrote:
>
>> you can also have multiple ipstacks, working ipv6 and what have you.
>> cinap fixed a bunch of stuff in this regard.
>> 
>> it's much more like linux network namespaces now, no limits to your
>> creativity...
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te43262c53bc71855-M564a8de6042cb6713cc304bc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 and Pine

[Charles Forsyth]

The ipaq/bitsy had no shortage of buttons round the case, several of which
were convenient when holding with one hand and using the stylus with the
other, so chording was possible.

On Thu, Apr 16, 2020 at 2:27 AM andrey mirtchovski 
wrote:

> unfortunately i don't remember anymore how many buttons were involved.
> nobody cared to take videos. i mostly used it with the stylus..
>
> On Wed, Apr 15, 2020 at 5:56 PM  wrote:
> > > 3rd ed ran on the bitsy, we had one at LANL:
> > >
> > > https://plan9.io/wiki/plan9/Installation_on_Ipaq/index.html
> > >
> > > t'was ok.
> >
> > How was the UI's reliance on chording and middle/right button
> > usage dealt with? That's what I see as the biggest challenge
> > for working well on phones.
> >

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tca918503d5b19459-Ma9314da58951eb51a7ac7d8c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Software preservation in the post-hg era

[Charles Forsyth]

I moved all my hg repositories to git some time ago

On Tue, Mar 31, 2020 at 7:39 PM Dave MacFarlane  wrote:

> On Tue, Mar 31, 2020 at 10:46 AM  wrote:
> > > If anyone has further thoughts, anything they want added, or any lists
> > > or indices of works they want archived/mirrored, I would love to see
> > > these posted.
> >
> > I think the lede got buried here, and people went of discussing git
> > clients.
> >
> > Given that the aptly-named bitbucket is deleting mercurial repositories,
> > is there anything of interest that should be retrieved before they empty
> > the bitbucket onto the curb?
> >
> 
> Is Inferno already mirrored?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M9682d3b12c0c9f00a4afed22
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] printing from Plan 9

[Charles Forsyth]

the downside is that you'd need to deal with CUPS!

On Sat, Sep 14, 2019 at 12:42 PM Richard Miller <9f...@hamnavoe.com> wrote:

> > You may be better off
> > sacrificing one of your old RPI boards to Linux and using that as your
> > common printer interface to the large set of supported printer devices
>
> Sounds practical.  Years ago I used a Mac for a CUPS server, until a
> MacOS opgrade suddenly made it stop working with lp(1), and I was too
> lazy to debug it.  Maybe time to try again with raspbian.
>
>
>

Re: [9fans] raspberry pi 4 arm64 test image

[Charles Forsyth]

Couldn't you even manage to try a few wines?

On Thu, Aug 22, 2019 at 9:59 AM Steve Simon  wrote:

> hi all
>
> just to say i am very excited abou the pi4 port but am on holiday in
> France at the moment so i cannot even help with testing.
>
> -Steve
>
>
> On 22 Aug 2019, at 9:07 am, Richard Miller <9f...@hamnavoe.com> wrote:
>
> >> oh dear. i dont even know the expected physical memory map...
> >> i guess that ram is continuous block at [0-0xfc00). but
> >> some memory might be reserved...
> >
> > No, the framebuffer is always reserved at the top of the
> > first 1GB, so on 2GB and 4GB units there are two separate
> > regions.
> >
> >> - atags
> >> - device tree /memory/reg property
> >> - firmware property request (getramsize() in vcore.c)
> >>
> >> for me getramsize() returns zero for both base and limit so its
> >> completely useless.
> >
> > That's strange, getramsize works on my 2GB pi4:
> >getramsize 0 1046478848
> >
> > The same values are in atags (you need 'device_tree=' in config.txt
> > to make the firmware pass atags instead of devicetree).
> >
>
>
>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

There is another existing variant of ESP32 with flash and RAM, and that one
would provide the external memory MMU.
It seems there could be a range from a small RT-ish kernel, with and
without a user mode, on little ESP32, to a Plan 9 kernel with a few
specialised processes on the bigger one.
An Inferno-like system might also straddle the boundaries.

On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth 
wrote:

> At a glance it looked as though the MMUs for the on-chip stuff were more
> suitable for Unix Seventh Edition (no later) than "full" Plan 9.
> The MMU for the external memory looked fine, but as I said, the device
> I've got, and several other boards based on WROOM seem not
> to bother with external memory. I didn't look widely, though.
>
> The processor is adequate, I think, but double == float (there's only
> single precision).
>
> The existing systems use one processor for applications, and the other
> mainly for communications.
>
> I haven't had a lot of spare time, but I did the assembler and am about
> 3/4 through the loader.
> For the most part it's a straightforward RISC.
> Might do the disassembler next to help debug the rest, and finally the
> compiler.
>
> On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic  wrote:
>
>> The emergent problem with IoT is the lack of security.  From my
>> understanding of Plan9's architecture. 9p protocol and the "root-less"
>> security model suggests to me that a Plan9 swarm of IoT devices could be
>> the "killer app" where Plan9 emerges on the strength of the vision of
>> decades ago.  Looking at other RT OSes the security models are often bolted
>> on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
>> and better networking than the early PCs.  From my tinkering and reverse
>> engineering of IoT devices, almost all use 8266 based WiFi and often in
>> conjunction with a uController. An ESP-32 is dual processor and with
>> sufficient I/O for most simple tasks.  With IoT, in general, you don't need
>> a lot of I/O, you simply throw more CPUs into the mix.
>>
>> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <
>> skip.tavakkol...@gmail.com> wrote:
>>
>>> I'm not sure if the effort would be worth it; but if you add support for
>>> esp32, I think it would be better for the os to be something like the one
>>> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
>>> Staying with FreeRTOS would need removal of GCC specific things from OS and
>>> dealing with lots of drivers in C++.
>>>
>>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem
>>> more appropriate for an "embedded" Plan 9.
>>>
>>> (*) for those who have not seen it, it is here:
>>> % ls -l /n/sources/contrib/forsyth/avr*
>>> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
>>> /n/sources/contrib/forsyth/avr.9gz
>>>
>>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <
>>> charles.fors...@gmail.com> wrote:
>>>
>>>> Since the resources are small if not tiny, a little systems analysis
>>>> and design is probably needed, but it looks like a bit of fun, until the
>>>> inevitable moment of "why am I here?".
>>>>
>>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <
>>>> charles.fors...@gmail.com> wrote:
>>>>
>>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen
>>>>> that use it bother with external memory,
>>>>> so memory is limited, especially the way it's partitioned.
>>>>>
>>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>>>> charles.fors...@gmail.com> wrote:
>>>>>
>>>>>> The ESP32 has got several MMUs. The characteristics are different
>>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, 
>>>>>> external
>>>>>> memory).
>>>>>> Some things are accessed using Memory Protection Units instead, which
>>>>>> control access by Process ID, but don't do mapping. Others including some
>>>>>> of the SRAMs are accessed through
>>>>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>>>>> SRAM0 and 2 choose protection for a given physical page as none, one or 
>>>>>> all
>>>>>> of PIDs 2 to 7, with the virtual address that
>>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>>>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

At a glance it looked as though the MMUs for the on-chip stuff were more
suitable for Unix Seventh Edition (no later) than "full" Plan 9.
The MMU for the external memory looked fine, but as I said, the device I've
got, and several other boards based on WROOM seem not
to bother with external memory. I didn't look widely, though.

The processor is adequate, I think, but double == float (there's only
single precision).

The existing systems use one processor for applications, and the other
mainly for communications.

I haven't had a lot of spare time, but I did the assembler and am about 3/4
through the loader.
For the most part it's a straightforward RISC.
Might do the disassembler next to help debug the rest, and finally the
compiler.

On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic  wrote:

> The emergent problem with IoT is the lack of security.  From my
> understanding of Plan9's architecture. 9p protocol and the "root-less"
> security model suggests to me that a Plan9 swarm of IoT devices could be
> the "killer app" where Plan9 emerges on the strength of the vision of
> decades ago.  Looking at other RT OSes the security models are often bolted
> on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
> and better networking than the early PCs.  From my tinkering and reverse
> engineering of IoT devices, almost all use 8266 based WiFi and often in
> conjunction with a uController. An ESP-32 is dual processor and with
> sufficient I/O for most simple tasks.  With IoT, in general, you don't need
> a lot of I/O, you simply throw more CPUs into the mix.
>
> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian 
> wrote:
>
>> I'm not sure if the effort would be worth it; but if you add support for
>> esp32, I think it would be better for the os to be something like the one
>> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
>> Staying with FreeRTOS would need removal of GCC specific things from OS and
>> dealing with lots of drivers in C++.
>>
>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more
>> appropriate for an "embedded" Plan 9.
>>
>> (*) for those who have not seen it, it is here:
>> % ls -l /n/sources/contrib/forsyth/avr*
>> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
>> /n/sources/contrib/forsyth/avr.9gz
>>
>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth 
>> wrote:
>>
>>> Since the resources are small if not tiny, a little systems analysis and
>>> design is probably needed, but it looks like a bit of fun, until the
>>> inevitable moment of "why am I here?".
>>>
>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <
>>> charles.fors...@gmail.com> wrote:
>>>
>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen
>>>> that use it bother with external memory,
>>>> so memory is limited, especially the way it's partitioned.
>>>>
>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>>> charles.fors...@gmail.com> wrote:
>>>>
>>>>> The ESP32 has got several MMUs. The characteristics are different
>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, 
>>>>> external
>>>>> memory).
>>>>> Some things are accessed using Memory Protection Units instead, which
>>>>> control access by Process ID, but don't do mapping. Others including some
>>>>> of the SRAMs are accessed through
>>>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>>>> SRAM0 and 2 choose protection for a given physical page as none, one or 
>>>>> all
>>>>> of PIDs 2 to 7, with the virtual address that
>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>>> privileged instructions.
>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>>>> translation. The external memory MMU is the most general (most
>>>>> conventional).
>>>>>
>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah  wrote:
>>>>>
>>>>>> esp32 doesn’t have an mmu, right?
>>>>>>
>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth 
>>>>>> wrote:
>>>>>>
>>>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>>>
>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic 
>>>>>> wrote:
>>>>>>
>>>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>>>
>>>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>>>
>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but
>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>>>
>>>>>>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

Since the resources are small if not tiny, a little systems analysis and
design is probably needed, but it looks like a bit of fun, until the
inevitable moment of "why am I here?".

On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth 
wrote:

> The device I've got is ESP32-WROOM-32. None of the boards I've seen that
> use it bother with external memory,
> so memory is limited, especially the way it's partitioned.
>
> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth 
> wrote:
>
>> The ESP32 has got several MMUs. The characteristics are different
>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>> memory).
>> Some things are accessed using Memory Protection Units instead, which
>> control access by Process ID, but don't do mapping. Others including some
>> of the SRAMs are accessed through
>> an MMU that can do virtual to physical mapping. The MMUs for internal
>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>> of PIDs 2 to 7, with the virtual address that
>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>> privileged instructions.
>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>> translation. The external memory MMU is the most general (most
>> conventional).
>>
>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah  wrote:
>>
>>> esp32 doesn’t have an mmu, right?
>>>
>>> On Jul 26, 2019, at 03:30, Charles Forsyth 
>>> wrote:
>>>
>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>
>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic 
>>> wrote:
>>>
>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>
>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>
>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>
>>>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

The device I've got is ESP32-WROOM-32. None of the boards I've seen that
use it bother with external memory,
so memory is limited, especially the way it's partitioned.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth 
wrote:

> The ESP32 has got several MMUs. The characteristics are different
> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
> memory).
> Some things are accessed using Memory Protection Units instead, which
> control access by Process ID, but don't do mapping. Others including some
> of the SRAMs are accessed through
> an MMU that can do virtual to physical mapping. The MMUs for internal
> SRAM0 and 2 choose protection for a given physical page as none, one or all
> of PIDs 2 to 7, with the virtual address that
> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
> privileged instructions.
> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
> translation. The external memory MMU is the most general (most
> conventional).
>
> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah  wrote:
>
>> esp32 doesn’t have an mmu, right?
>>
>> On Jul 26, 2019, at 03:30, Charles Forsyth 
>> wrote:
>>
>> I was thinking of doing that since I've got an ESP-32 for some reason
>>
>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic  wrote:
>>
>>> I was reading the post Why Didn't Plan 9 Succeed
>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>
>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>
>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>
>>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

The ESP32 has got several MMUs. The characteristics are different depending
on the part that a given MMU accesses (flash, ROM, SRAM, external memory).
Some things are accessed using Memory Protection Units instead, which
control access by Process ID, but don't do mapping. Others including some
of the SRAMs are accessed through
an MMU that can do virtual to physical mapping. The MMUs for internal SRAM0
and 2 choose protection for a given physical page as none, one or all of
PIDs 2 to 7, with the virtual address that
maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
privileged instructions.
A large chunk of SRAM (SRAM 1) has only Memory Protection and no
translation. The external memory MMU is the most general (most
conventional).

On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah  wrote:

> esp32 doesn’t have an mmu, right?
>
> On Jul 26, 2019, at 03:30, Charles Forsyth 
> wrote:
>
> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic  wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

I've not previously seen an architecture where so many cache and TLB
control instructions were in the primary space and took up so much of it.


On Fri, Jul 26, 2019 at 11:30 AM Charles Forsyth 
wrote:

> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic  wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

I'd need a letter or number and thought about reusing x (xa/xc/xl) since
the AT DSP is long gone

On Fri, Jul 26, 2019 at 11:30 AM Charles Forsyth 
wrote:

> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic  wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

I was thinking of doing that since I've got an ESP-32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic  wrote:

> I was reading the post Why Didn't Plan 9 Succeed
>  on Hacker News.
>
> Made me think that Plan 9 for IoT system of systems could be viable.
>
> To that end, ESP-32 modules look capable enough to run Plan 9, but is
> there a Plan 9 C compiler for Xtensa ISA CPUs?
>
>

Re: [9fans] 5c bug

[Charles Forsyth]

5c shouldn't discard the cast, which implies a mask, but you should also
rewrite the code as you suggest.
(it's not just 5c, since it's the same for several other RISCy ones.)


On Thu, Jul 25, 2019 at 12:20 PM Steve Simon  wrote:

> Hi,
>
> I traced a long standing cifs issue to 5c the compiler.
>
> The code in lib9p to validate wstat calls
> uses a neat bit of casting which fails when using 5c.
>
> /sys/src/lib9p/srv.c:658-669
>
> These following lines missfire reporting type or qid change
> when trying to rename files over cifs.
>
> if((ushort)~r->d.type){
> ...
> if((uchar)~r->d.qid.type || .. ){
>
> but rewriting them like this makes the code work as expected:
>
> if(r->d.type != (ushort)~0){
> ...
> if(r->d.qid.type != (uchar)~0 || ... )
>
> Personally I am happy to hack lib9p but the worry is that
> this bug might be affecting other things.
>
> I have no knowledge of the internals of the compilers so
> I am afraid I have made no attempt to dig deeper.
>
> -Steve
>
>

Re: [9fans] Anyone have a Plan 9 4th Edition Manual Set...

[Charles Forsyth]

The main problem is the postage at 2.7Kg even at Printed Paper rate (which
also doesn't work at all for Canada or Cameroon if over 2Kg).

On Sun, Jun 30, 2019 at 8:09 PM Kurt H Maier  wrote:

> On Sun, Jun 30, 2019 at 09:32:29AM -0700, Lyndon Nerenberg wrote:
> > michaelian ennis writes:
> >
> > > I found a second edition set on Abe books last year.  They were not
> > > inexpensive.
> >
> > Sadly, Abebooks became utterly useless several years ago, when it was
> > taken over by bots scraping each other listings and adding 5%.
>
> In other words, Amazon bought it.  My copies came from Alibris, and they
> were not a set; I bought them each individually for extremely cheap by
> searching the ISBNs directly.
>
> khm
>
>

Re: [9fans] linux 9p: uid & gid

[Charles Forsyth]

4294967294 probably started off as -2, which some systems used for user
"nobody"

On Thu, Jun 20, 2019 at 4:04 PM Oleg  wrote:

> Hi, all.
>
> I wrote a 9p fs with help of libixp and after mounting i see strange uid
> and
> gid numbers for files:
>
> ~# mount -t 9p -o trans=unix,noextend q t
> ~# ls -l t
> -rw-rw-rw- 1 4294967294 4294967294 1 Jan  1  1970 conf
> -rw-rw-rw- 1 4294967294 4294967294 1 Jan  1  1970 data
> -rw-rw-rw- 1 4294967294 4294967294 1 Jan  1  1970 stat
>
> If i do mount with dfltuid and dfltgid, i get normal values:
>
> ~# mount -t 9p -o
> trans=unix,noextend,trans=unix,noextend,dfltuid=0,dfltgid=0 q t
> ~# ls -l t
> -rw-rw-rw- 1 root root 1 Jan  1  1970 conf
> -rw-rw-rw- 1 root root 1 Jan  1  1970 data
> -rw-rw-rw- 1 root root 1 Jan  1  1970 stat
>
> But in any case chown call to these files sends empty uid and gid strings
> in
> wstat T-message.
>
> Is there any way to make uid & gid works as expected?
>
> Thanks.
>
> --
> Олег Неманов (Oleg Nemanov)
>
>

Re: [9fans] POSIX shared memory (shm_open)

[Charles Forsyth]

There's some support for sharing memory segments in segattach(2) and
between unrelated processes with segment(3).

On Wed, 24 Apr 2019 at 16:23, Lassi Kortela  wrote:

> Hello,
>
> Can the POSIX shared memory API be emulated on Plan 9 with reasonable
> effort? I didn't find any mention of 'shm_open' in Plan 9 source.
>
> To recap, the API works as follows:
>
> - shm_open(path) to open or create an shm object, get a file descriptor
> - shm_unlink(path) to remove the shm object from the path namespace
> - ftruncate(fd) to actually allocate n bytes for the shm object
> - fstat(fd) returns the size of the object in the st_size field
> - mmap(fd) to get a pointer to use the shared memory
>
> The shm fd works like other Unix fds (can be sent to an unrelated
> process over a Unix-domain socket, persists over fork(), and can persist
> over exec() if the close-on-exec flag is cleared). The kernel garbage
> collects the shm object after the last fd pointing to it is closed.
>
> I made the shim  to provide a
> "shm_open() without a pathname" on various Unix flavors. I'm wondering
> if Plan 9 support could be easily added.
>
> I should mention that I have never used Plan 9, just read some of the
> source and documentation.
>
> Regards,
> Lassi
>
>

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a struct?

[Charles Forsyth]

yes, how true.

On Tue, 2 Apr 2019 at 18:22, Devon H. O'Dell  wrote:

> Also worth noting that any padding bits are zeroed as well for
> aggregate and union types. Not just setting all pointer values to NULL
> and arithmetic types to positive or unsigned zero.
>
> Op di 2 apr. 2019 om 08:17 schreef Skip Tavakkolian
> :
> >
> > like this:
> >
> > #include 
> > #include 
> >
> > struct option {
> > int n;
> > char *s;
> > int flags;
> > };
> >
> >
> > int main(void)
> > {
> > struct option opt = { 1, "test" };
> > static struct option opt2;
> >
> > printf("%d %s %x\n", opt.n, opt.s, opt.flags);
> > printf("%x\n", opt2.flags);
> > return 0;
> > }
> >
> >
> > On Tue, Apr 2, 2019 at 8:02 AM Skip Tavakkolian <
> skip.tavakkol...@gmail.com> wrote:
> >>
> >> I interpret it as: initialize it like a static variable.
> >>
> >> On Tue, Apr 2, 2019 at 7:53 AM Kyohei Kadota  wrote:
> >>>
> >>> Thank you for a reply.
> >>>
> >>> I read spec on
> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> >>> then I'm confusing.
> >>> This spec describes Initialization:
> >>>
> >>> > 6.7.8 Initialization, p127
> >>> >
> >>> > 19 The initialization shall occur in initializer list order, each
> initializer provided for a
> >>> > particular subobject overriding any previously listed initializer
> for the same subobject;132)
> >>> > all subobjects that are not initialized explicitly shall be
> initialized implicitly the same as
> >>> > objects that have static storage duration.
> >>>
> >>> What is "be initialized implicitly the same as objects that have
> >>> static storage duration" mean?
> >>>
> >>> 2019年4月2日(火) 9:27 Jeremy O'Brien :
> >>> >
> >>> > On Mon, Apr 1, 2019, at 11:33, Kyohei Kadota wrote:
> >>> > > Hi, 9fans. I use 9legacy.
> >>> > >
> >>> > > About below program, I expected that flags field will initialize to
> >>> > > zero but the value of flags was a garbage, ex, "f8f7".
> >>> > > Is this expected?
> >>> > >
> >>> > > ```
> >>> > > #include 
> >>> > >
> >>> > > struct option {
> >>> > > int n;
> >>> > > char *s;
> >>> > > int flags;
> >>> > > };
> >>> > >
> >>> > > int
> >>> > > main(void)
> >>> > > {
> >>> > > struct option opt = {1, "test"};
> >>> > > printf("%d %s %x\n", opt.n, opt.s, opt.flags);
> >>> > > return 0;
> >>> > > }
> >>> > > ```
> >>> > >
> >>> > >
> >>> >
> >>> > According to C99: "If an object that has automatic storage duration
> is not initialized explicitly, its value is indeterminate."
> >>> >
> >>> > Stack variable == automatic storage duration. This appears to be
> correct behavior to me.
> >>> >
> >>>
>
>

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a?struct?

[Charles Forsyth]

covered and covered1

On Tue, 2 Apr 2019 at 17:26, Anthony Martin  wrote:

> Charles Forsyth  once said:
> > I didn't look at the code closely enough earlier, but remembered
> something
> > from years ago this morning. It's a bug. It isn't platform specific.
> > There is an existing fix in 9front (I think it came from there) but it's
> > horrible. Still, better a horrible fix than buggy code, so I'll apply it
> to
> > the 9legacy version as well.
>
> It's in /sys/src/cmd/cc/dcl.c:/^contig
>
> What was horrible about the fix?
>
>   Anthony
>
>

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a struct?

[Charles Forsyth]

> What is "be initialized implicitly the same as objects that have
> static storage duration" mean?


It refers back to the second part of case 10 of that section.

On Tue, 2 Apr 2019 at 15:53, Kyohei Kadota  wrote:

> Thank you for a reply.
>
> I read spec on http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> then I'm confusing.
> This spec describes Initialization:
>
> > 6.7.8 Initialization, p127
> >
> > 19 The initialization shall occur in initializer list order, each
> initializer provided for a
> > particular subobject overriding any previously listed initializer for
> the same subobject;132)
> > all subobjects that are not initialized explicitly shall be initialized
> implicitly the same as
> > objects that have static storage duration.
>
> What is "be initialized implicitly the same as objects that have
> static storage duration" mean?
>
> 2019年4月2日(火) 9:27 Jeremy O'Brien :
> >
> > On Mon, Apr 1, 2019, at 11:33, Kyohei Kadota wrote:
> > > Hi, 9fans. I use 9legacy.
> > >
> > > About below program, I expected that flags field will initialize to
> > > zero but the value of flags was a garbage, ex, "f8f7".
> > > Is this expected?
> > >
> > > ```
> > > #include 
> > >
> > > struct option {
> > > int n;
> > > char *s;
> > > int flags;
> > > };
> > >
> > > int
> > > main(void)
> > > {
> > > struct option opt = {1, "test"};
> > > printf("%d %s %x\n", opt.n, opt.s, opt.flags);
> > > return 0;
> > > }
> > > ```
> > >
> > >
> >
> > According to C99: "If an object that has automatic storage duration is
> not initialized explicitly, its value is indeterminate."
> >
> > Stack variable == automatic storage duration. This appears to be correct
> behavior to me.
> >
>
>

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a?struct?

[Charles Forsyth]

>
> In the present case, this appears to be a compiler bug. The aforementioned
> reference to n1548 sec 6.7.9 para 10 is incorrect in that there _is_ an
> explicit initializer here. The relevant text in the standard is sec 6.7.9
> pp 16-21, which specifies that in the event that an explicit initializer
> does not completely cover (in a topological sense) the thing it is
> initializing, then the elements not covered shall be initialized as if they
> had _static_ storage duration; that is, they should be zeroed.


I didn't look at the code closely enough earlier, but remembered something
from years ago this morning. It's a bug. It isn't platform specific.
There is an existing fix in 9front (I think it came from there) but it's
horrible. Still, better a horrible fix than buggy code, so I'll apply it to
the 9legacy version as well.

On Tue, 2 Apr 2019 at 03:23, Kurt H Maier  wrote:

> On Mon, Apr 01, 2019 at 09:20:43PM -0400, Dan Cross wrote:
> > On Mon, Apr 1, 2019 at 8:36 PM Kurt H Maier  wrote:
> >
> > > On Mon, Apr 01, 2019 at 08:26:30PM -0400, Jeremy O'Brien wrote:
> > > > On Mon, Apr 1, 2019, at 11:33, Kyohei Kadota wrote:
> > > > > Hi, 9fans. I use 9legacy.
> > > > >
> > > > > About below program, I expected that flags field will initialize to
> > > > > zero but the value of flags was a garbage, ex, "f8f7".
> > > > > Is this expected?
> > > > >
> > > > > ```
> > > > > #include 
> > > > >
> > > > > struct option {
> > > > > int n;
> > > > > char *s;
> > > > > int flags;
> > > > > };
> > > > >
> > > > > int
> > > > > main(void)
> > > > > {
> > > > > struct option opt = {1, "test"};
> > > > > printf("%d %s %x\n", opt.n, opt.s, opt.flags);
> > > > > return 0;
> > > > > }
> > > > > ```
> > > > >
> > > > >
> > > >
> > > > According to C99: "If an object that has automatic storage duration
> is
> > > not initialized explicitly, its value is indeterminate."
> > > >
> > > > Stack variable == automatic storage duration. This appears to be
> correct
> > > behavior to me.
> > > >
> > >
> > > Can anyone provide the patches 9legacy uses to implement C99
> compliance?
> >
> >
> > There were actually quite a few of them, mostly done by Geoff Collyer.
> The
> > compiler sources list contains a list of desiderata in a file called
> `c99`;
> > of course, the plan9 compilers aren't completely compliant (they weren't
> > trying to be). Incidentally this file has been carried forward into, for
> > example, /sys/src/cmd/cc/c99 in the 9front distribution (and other plan9
> > derivatives).
> >
> > In the present case, this appears to be a compiler bug. The
> aforementioned
> > reference to n1548 sec 6.7.9 para 10 is incorrect in that there _is_ an
> > explicit initializer here. The relevant text in the standard is sec 6.7.9
> > pp 16-21, which specifies that in the event that an explicit initializer
> > does not completely cover (in a topological sense) the thing it is
> > initializing, then the elements not covered shall be initialized as if
> they
> > had _static_ storage duration; that is, they should be zeroed.
> >
> > Now as I said, the Plan 9 C compilers aren't explicit C99 compliant. But
> > given that the `c99` file describes things related to initializer lists
> as
> > being unneeded because they were already implemented, one may assume it
> was
> > believed that this was covered by c99 behavior. It isn't.
> >
> > - Dan C.
>
> So, no?
>
> khm
>
>

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a struct?

[Charles Forsyth]

Yes, that's normal C behaviour. Only external and static storage is
guaranteed to be zero. In a modern environment it seems a little mean,
especially since you gave opt a partial initial value, but there are no
half-measures in C.

On Tue, 2 Apr 2019 at 01:27, Jeremy O'Brien  wrote:

> On Mon, Apr 1, 2019, at 11:33, Kyohei Kadota wrote:
> > Hi, 9fans. I use 9legacy.
> >
> > About below program, I expected that flags field will initialize to
> > zero but the value of flags was a garbage, ex, "f8f7".
> > Is this expected?
> >
> > ```
> > #include 
> >
> > struct option {
> > int n;
> > char *s;
> > int flags;
> > };
> >
> > int
> > main(void)
> > {
> > struct option opt = {1, "test"};
> > printf("%d %s %x\n", opt.n, opt.s, opt.flags);
> > return 0;
> > }
> > ```
> >
> >
>
> According to C99: "If an object that has automatic storage duration is not
> initialized explicitly, its value is indeterminate."
>
> Stack variable == automatic storage duration. This appears to be correct
> behavior to me.
>
>

Re: [9fans] microsoft's plan 9 distribution

[Charles Forsyth]

I thought I remembered the name Brian Perkins until I realised that was a
Radio 4 newsreader.

On Sat, 16 Feb 2019 at 08:54, Steve Simon  wrote:

> interesting...
>
> the first thing, can you convince the 9p server to offer 9p over tcp?
> then, can explorer mount my plan9 file server?
>
> the biggest surprised is that i don't recognise any of the names of the
> team listed as 9fans of old.
>
> -Steve
>
> >> On 16 Feb 2019, at 3:57 am, Lucio De Re  wrote:
> >>
> >>> On 2/16/19, Kurt H Maier  wrote:
> >>> On Sat, Feb 16, 2019 at 01:48:01AM +0100, hiro wrote:
> >>>
> https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/
> >>
> >> Just when the linux kids finally gave up on 9p2000.l, and introduced
> >> virtio-fs, Microsoft shows up to ensconce 9p forever.
> > I wonder what the long-term plan really is, though? Process-level
> > namespaces? If they can do that, they will leave Linux standing.
> >
> > Lucio.
>
>
>

Re: [9fans] microsoft's plan 9 distribution

[Charles Forsyth]

well spotted

On Sat, 16 Feb 2019 at 00:48, hiro <23h...@gmail.com> wrote:

>
> https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/
>
>

Re: [9fans] Plan 9 64-bit?

[Charles Forsyth]

I still run a version of that kernel on my cpu servers and some other
devices. There might be some changes I've made that I haven't pushed yet.
Unfortunately, I haven't had much time for systems work for a good year or
more, so I haven't merged in changes made elsewhere.


On Wed, 30 Jan 2019 at 09:18, Giacomo Tesio  wrote:

> Not sure if anybody cares, but Jehanne's kernel derives from a version
> of Charles https://bitbucket.org/forsyth/plan9-9k cherry picked from
> 2015.
>
>
> Giacomo
>
>

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

[Charles Forsyth]

I was the one that replaced Alpha by ARM64 as 7 for Plan 9.

On Wed, 31 Oct 2018 at 13:44, Ethan Gardener  wrote:

> On Tue, Oct 30, 2018, at 3:37 PM, Steve Simon wrote:
> >
> > There once was a vax port but i don’t know what its letter was.
>
> Well, 7 used to be Alpha.  I remember someone being very annoyed because
> he still had Alpha hardware when the Go team decided to use 7 for Arm64.
>
>

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

[Charles Forsyth]

I used Ka/Kb/Kc (upper case) for my Fairchild Clipper port, but that
doesn't work on case-insensitive file systems.
I did once make the changes for unicode, but again there can be problems
with non-Plan9 file systems, even now.



On Tue, 30 Oct 2018 at 12:43, Ethan Gardener  wrote:

> On Tue, Oct 30, 2018, at 4:52 AM, Lucio De Re wrote:
>  >
> > Is there a technical reason (beside fonts that do not cover them) not
> > to use a Unicode values for the first letter?
>
> Not a major reason, but at least one of Plan 9's build tools compares them
> as C chars, and would need to be fixed.  I can't remember which one it is
> right now.
>
> --
> Progress might have been all right once, but it has gone on too long --
> Ogden Nash
>
>

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

[Charles Forsyth]

This was my old list for comparison

.a ar(1) archive
.b bc(1), limbo source
.c C source
.d dc(1)
.e -- was efl
.f fortran
.g -- there was a gc?
.h C include
.i na(8) output
.j
.k ka, kc, kl
.l lc(1), lex
.m mc(1), limbo module source
.n na(8)
.o unix object files
.p pascal source?
.q qa, qc, ql power
.r rc(1), ratfor
.s assembler source
.t tc, with 5a/5l arm (thumb)
.u uc sparc64
.v va, vc, vl mips
.w wc(1)
.x -- old xa, xc, xl
.y -- yacc
.z za, zc, zl [VN atmel compiler]
.0 0[acl] spim
.1 1a, 1c, 1l 68010
.2 2[acl] 68020
.3 -- free (perhaps sh-3)
.4 64-bit mips?
.5 5a, 5c, 5l arm
.6 6a, 6c, 6l amd64
.7 7a, 7c, 7l arm64
.8 8a, 8c, 8l 386
.9 p9p, 9[acl] power64


On Tue, 30 Oct 2018 at 09:35, Anthony Martin  wrote:

> Charles Forsyth  once said:
> > I had a chart somewhere with the available non-unicode letters.
>
> I made one a few years ago. It's at http://pbrane.org/comp.html
>
> I just updated it with a suggestion for the RISC-V letters.
>
>   Anthony
>
>

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

[Charles Forsyth]

It's z because the Atmel AVR is the last thing you'd want to use. (As
usual, once you've got C going, it's ok, except for the design bugs.)
They were in the Berkeley mote, which we worked on years ago, later on
custom hardware, but always with completely different software from
Berkeley's.
I had little processes. The loader minimised register saves on interrupts.

I had a chart somewhere with the available non-unicode letters.

On Mon, 29 Oct 2018 at 14:07, Richard Miller <9f...@hamnavoe.com> wrote:

>
> I think I have sources for the z[acl] suite somewhere. You make it
>> sound like maybe I should give them back to Charles
>>
>
> What architecture is that for?  I picked 'z' for riscv hoping there wasn't
> a collision, but I can change it.
>
>

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

[Charles Forsyth]

He wants something I think that generates code that will run on unixy
systems, and there isn't one, except in specialised ways.

On Sun, 28 Oct 2018 at 14:20, Skip Tavakkolian 
wrote:

> Inferno sources include kencc that build on the target os/arch.
>
> On Sun, Oct 28, 2018, 5:41 AM  wrote:
>
>> Richard Miller <9f...@hamnavoe.com> wrote:
>>
>> > That's for Plan 9 use.  I should also configure a version to run on
>> > posix-type systems and put that on github.
>>
>> Is there a standalone version of the Plan 9 C compiler for *nix
>> for x86 / x86_64?
>>
>> I'm looking for something easy to bring up and install to use an
>> an additional compiler for testing a Free Software project.
>>
>> Thanks,
>>
>> Arnold
>>
>>

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

[Charles Forsyth]

> I'll see if I wrote up some of it. I think there were manual pages for the
>> Messages replacing Blocks.
>
>
Here are the three manual pages  https://goo.gl/Qykprf
It's not obvious from them, but internally a Fragment can represent a slice
of a Segment*

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

[Charles Forsyth]

They are machines designed to run programs most people do not write!

On Mon, 15 Oct 2018 at 19:20, hiro <23h...@gmail.com> wrote:

> > Also, NUMA effects are more important in practice on big multicores. Some
> > of the off-chip delays are brutal.
>
> yeah, we've been talking about this on #cat-v. even inside one CPU
> package amd puts multiple dies nowadays, and the cross-die cpu cache
> access delays are approaching the same dimensions as memory-access!
>
> also on each die, they have what they call ccx (cpu complex),
> groupings of 4 cores, which are connected much faster internally than
> towards the other ccx
>
>