Re: [9fans] openat()

[Gorka Guardiola]

On Fri, Apr 5, 2024, 23:49 Alyssa M via 9fans <9fans@9fans.net> wrote:

> Are you thinking narrowly about "What changes to the Plan 9 kernel would
> you make to emulate the Linux openat() system call" or more generally about
> "How would you design a facility for plan 9 that provides an equivalent
> service?
>

Yes, this is what I understood between my first answer and the second. You
don't want to rewalk the path and you already have the fid with the
directory part walked in the chan of dirfd. I think that if you walk the
remaining path from that chan (cloning it) you preserve the same guarantees
provided by openat.



> As I understand it from the rationale section on the linux man page, the
> call exists to avoid a race condition between checking that a directory
> exists and doing something to a path containing it. An additional motivator
> is providing the effect of additional current working directories notably
> for Linux threads (which presumably don't have their own. I think
> 'threads'  (processes that share memory) on Plan 9 do???).
>
> This is all based on the assumption that holding a file/directory open
> keeps it alive and in existence... which on Plan 9, I think it doesn't,
> does it? As I understand it, remove can remove a file or directory that is
> open, which is not like UNIX/Linux...
>
> Sorry, I'm just trying to understand the question.
>
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M1c147cadc76c65a4fbb9aa76
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of
the dirfd and walk just the remainder cloning it and creating a new one.
That way the openat provides the guarantees you want.

On Fri, Apr 5, 2024, 22:15 Gorka Guardiola  wrote:

> I mean, if you want a new syscall jus copy or call the implementation of
> these.
>
>
> On Fri, Apr 5, 2024, 22:12 Gorka Guardiola  wrote:
>
>> ¿Isn't that fd2path, strcat and open?
>> Or am I misunderstanding something?
>>
>> On Fri, Apr 5, 2024, 21:51 ron minnich  wrote:
>>
>>> One of the folks I worked with, when we pulled a big chunk of plan 9
>>> into akaros, commented that he had implemented openat on akaros.
>>>
>>> I don't want this to turn into a debate on the merits of openat; I am
>>> more curious: if you went to implement openat on Plan 9, how would you go
>>> about it? I have a few ideas but I'm more interested in your ideas.
>>>
>>> Thanks
>>> *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/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293>
>>>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M43026122c2960e83ab07e80b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

I mean, if you want a new syscall jus copy or call the implementation of
these.


On Fri, Apr 5, 2024, 22:12 Gorka Guardiola  wrote:

> ¿Isn't that fd2path, strcat and open?
> Or am I misunderstanding something?
>
> On Fri, Apr 5, 2024, 21:51 ron minnich  wrote:
>
>> One of the folks I worked with, when we pulled a big chunk of plan 9 into
>> akaros, commented that he had implemented openat on akaros.
>>
>> I don't want this to turn into a debate on the merits of openat; I am
>> more curious: if you went to implement openat on Plan 9, how would you go
>> about it? I have a few ideas but I'm more interested in your ideas.
>>
>> Thanks
>> *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/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293>
>>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0fdda14083bc18f0e59c774f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

¿Isn't that fd2path, strcat and open?
Or am I misunderstanding something?

On Fri, Apr 5, 2024, 21:51 ron minnich  wrote:

> One of the folks I worked with, when we pulled a big chunk of plan 9 into
> akaros, commented that he had implemented openat on akaros.
>
> I don't want this to turn into a debate on the merits of openat; I am more
> curious: if you went to implement openat on Plan 9, how would you go about
> it? I have a few ideas but I'm more interested in your ideas.
>
> Thanks
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M9023f4cd7b382f26249c302b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Codebase navigation and using tags files in acme

[Gorka Guardiola]

I am guessing:
https://github.com/google/codesearch/blob/master/cmd/csearch/csearch.go

On Thu, Aug 19, 2021, 13:44 Maurizio Boriani  wrote:

>
> Rob Pike writes:
>
> > % cat bin/cf
> > #!/bin/sh
> >
> > csearch -n -f '\.go$' '^func (\([^)]+\) )?'$1'\('
> 
> thanks a lot! But... what's csearch?
> 
> best,
> 
> --
> Maurizio Boriani
> GPG key: 0xCC0FBF8F

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf8ceac12df9da674-M7158507c2960444d94482c79
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Gorka Guardiola]

Really great work. Thanks for putting in the time to make this possible.

G.


On Tue, Mar 23, 2021 at 2:07 PM  wrote:

> We are thrilled to announce that Nokia has transferred the copyright of
> Plan 9 to the Plan 9 Foundation. This transfer applies to all of the
> Plan 9 from Bell Labs code, from the earliest days through their final
> release.
> 
> The most exciting immediate effect of this is that the Plan 9 Foundation
> is making the historical 1st through 4th editions of Plan 9 available
> under the terms of the MIT license. These are the releases as they
> existed at the time, with minimal changes to reflect the above.
> 
> 1st and 2nd edition were never released as open source software, and
> both (but especially 1st edition) were only available to a very small
> number of people. 3rd and 4th were previously available as open source,
> but under a license which was problematic for some people (especially
> the 3rd edition). We think making these available under the MIT license
> is something that's going to be a significant benefit for all projects
> using Plan 9 code. While this doesn't automatically change the license
> on any downstream projects, and you're welcome to keep using the LPL if
> you like, you now have the option of switching to MIT, which we think
> most everyone will find preferable.
> 
> Obviously, for folks in the Plan 9 community, there isn't a way to say
> "thank you" to Bell Labs, and its various parent organizations, that's
> really adequate. None of us would be talking about any of this if it
> weren't for the work done there for decades. All of us here at the Plan
> 9 Foundation express our sincerest thanks to the team at Nokia who made
> this possible, the Plan 9 alumni who supported the effort, and the Plan
> 9 community who have kept kernels booting and the userland useful.
> 
> The historical releases are available right now at:
> https://p9f.org/dl/
> 
> You can read Nokia's press release on the transfer here:
> 
> https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/
> 
> Thank you for your time,
> Anthony Sorace
> Plan 9 Foundation


-- 
- curiosity sKilled the cat

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M7a43dca2d2e65eedc4c64485
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sad news.

[Gorka Guardiola]

Yes, very sad. Condolences to the family.


On Mon, Sep 28, 2020, 20:33 Dan Cross  wrote:

> I just got word that Andrey has passed away. :-(
>
> I'm sorry, I don't have any further details right now, but wanted to let
> folks know.
>
> - Dan C.
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T89f7af873f4109c5-Mbf3b1d3b1dc94d13ea63a237
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Jim McKie

[Gorka Guardiola]

Very sad news. He will be sorely missed.

On Thu, Jun 25, 2020, 02:36 Charles Forsyth 
wrote:

> I am sorry to say that Jim McKie (jmk) died suddenly on 16 June.
> https://www.ippolitofuneralhomes.com/obituaries/James-B-McKie?obId=15111702=IwAR3d7aHZXEOhYz-ciOrQPh-W1eMw-_8MHiCUdeKOxzLBEI6VGHsSn4aTjdk
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

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

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

[Gorka Guardiola]

Not that I know of. People moved on to other projects afaik.

On Sat, Dec 29, 2018, 14:09 Mayuresh Kathe  Yes, that's the one, thanks for that pointer Gorka, many thanks indeed.
> Anyone still working on "Nix Mark IV"?
>
> On 2018-12-29 06:26 PM, Gorka Guardiola wrote:
> > Is it nix you are asking about?http://lsub.org/ls/nix.html [1]
> >
> > On Sat, Dec 29, 2018, 13:44 Mayuresh Kathe  >
> >> I can't remember the name of the person, but he used to work for a
> >> European research lab and had made a 64-bit version of an operating
> >> system derived from Plan 9. That operating system had some
> >> interesting
> >> features, one of which was the ability to isolate a process on a
> >> single
> >> core of a CPU.
> >>
> >> Does anyone have more details about that operating system? Or would
> >> anyone know the name of that person?
> >> It would be nice to work with that operating system and I would be
> >> willing to pay a license fee to use it if granted access to the
> >> source
> >> for personal study.
> >>
> >> Thanks,
> >>
> >> ~Mayuresh
>
>
>

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

[Gorka Guardiola]

Is it nix you are asking about?
http://lsub.org/ls/nix.html

On Sat, Dec 29, 2018, 13:44 Mayuresh Kathe  I can't remember the name of the person, but he used to work for a
> European research lab and had made a 64-bit version of an operating
> system derived from Plan 9. That operating system had some interesting
> features, one of which was the ability to isolate a process on a single
> core of a CPU.
>
> Does anyone have more details about that operating system? Or would
> anyone know the name of that person?
> It would be nice to work with that operating system and I would be
> willing to pay a license fee to use it if granted access to the source
> for personal study.
>
> Thanks,
>
> ~Mayuresh
>
>
>

Re: [9fans] usb serial on raspberry pi (again)

[Gorka Guardiola]

On Mon, Dec 12, 2016 at 9:39 PM, Richard Miller <9f...@hamnavoe.com> wrote:

> Oops, pressed the wrong button - that reply was intended for
> Steve Simon and not the whole of 9fans.  Oh well, if anybody
> else wants to rummage through the usbdwc driver too, they
> are welcome.
>


Thanks, because I had been looking at the silabs code and was puzzled
(I don't own a pi now for different reasons). Good to know you are on it
:-).

G.

Re: [9fans] usb disk - no partitions?

[Gorka Guardiola]

Last time I looked at it did not.
You would use some other
fs (partfs, for example) for that.

G.


On Tue, Jul 21, 2015 at 10:51 AM, Steve Simon st...@quintile.net wrote:
 the usb disk driver does not seem to support partitions,
 Am I doing somthing wrong, or is that just how it is?

 e.g.

 cherry% ls /dev/sdU0.0/
 /dev/sdU0.0/ctl
 /dev/sdU0.0/data
 /dev/sdU0.0/raw

 cherry% disk/fdisk -p /dev/sdU0.0/data  /dev/sdU0.0/ctl

 cherry% ls /dev/sdU0.0/
 /dev/sdU0.0/ctl
 /dev/sdU0.0/data
 /dev/sdU0.0/raw

 -Steve




-- 
- curiosity sKilled the cat

Re: [9fans] New /prog idea

[Gorka Guardiola]

There was a proc box in the original Plan B of which there were different
version in the descendants (for files too) and
which permitted things similar to what you want. See

http://lsub.org/ls/export/man.1e.ps (page 31)
and
http://lsub.org/ls/export/ubiterm.icps05.pdf

Later, Andrey and Ron did something similar for clusters with xcpu:

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04100349

G.



On Sun, May 4, 2014 at 11:59 PM, Oleksandr Iakovliev
yshu...@lynxline.comwrote:


 Just idea, but seriously, why cannot do something like this:

 # cat /prog/new  $id
 # cat /dis/ls.dis  /prog/$id/dis
 # echo /  /prog/$id/cwd
 # echo «Running»  /prog/$id/status

 Not to do it which echo/cat, but to have remote access to /prog/new




-- 
- curiosity sKilled the cat

Re: [9fans] more serial questions

[Gorka Guardiola]

I didn't add that, your guess is as good as mine.

G.

 On Mar 25, 2014, at 1:12 AM, erik quanstrom quans...@quanstro.net wrote:
 
 i'm just asking questions, because i don't have the experience the author
 clearly has.
 
 i'm looking at this comment
 
/*
 * if we encounter a long run of continuous read
 * errors, do something drastic so that our caller
 * doesn't just spin its wheels forever.
 */
 
 long run is defined to be 1 for the lifetime of all serial ports.  i'm 
 thinking
 of making this 5 in a row per call, and checking for a few more cant continue
 type messages.  was there a particular device that might spit out hundreds of
 consecutive read timeouts (that's the only error this works for) before 
 returning
 something?  could the same thing happen on write?
 
 - erik
 

Re: [9fans] usb/serial control open

[Gorka Guardiola]

On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom quans...@quanstro.net wrote:
 it seems odd to me that opening the ctl file would
 reset some serial parameters.  wouldn't it be better
 to leave them alone?


What do you return on read if you don´t know the state?
For some devices if you don´t set the state, you have no idea.
You can do it in read, but it seemed more intuitive in open at the
time, (and you don´t
set the state on every read).


G.

Re: [9fans] usb/serial control open

[Gorka Guardiola]

 so if i do this

 echo l7/dev/eiaU6/eiaUctl
 cat /dev/eiaU6/eiaUctl

 that's two opens, isn't it?  then isn't l reset to 8 by the second
 open?


It has been a while and I don´t have the code at hand now, but once
it is at a known state, it shouldn´t set it again, that is probably a bug.

It should be something like:

if(!setonce){
  setonce = 1;
  serialctl(p, l8 i1);  /* default line parameters */
}

G.

Re: [9fans] usb/serial control open

[Gorka Guardiola]

 What do you return on read if you don´t know the state?
 For some devices if you don´t set the state, you have no idea.
 You can do it in read, but it seemed more intuitive in open at the
 time, (and you don´t
 set the state on every read).


What I meant, is if you
write then read, the read does not set the state.
if you read then write, it does.
It is cleaner to set it on open.

The rule is simple, the first open sets the state.
As I said, the first part is missing :-).

G.

Re: [9fans] usb/serial control open

[Gorka Guardiola]

On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola pau...@gmail.com wrote:


 if(!setonce){
   setonce = 1;
   serialctl(p, l8 i1);  /* default line parameters */
 }

And setonce needs to live in the interface, and it needs to be locked, etc.
G.

Re: [9fans] usb/serial control open

[Gorka Guardiola]

 And setonce needs to live in the interface, and it needs to be locked, etc.

 another idea: since this is only needed by some hardware.  and then only in 
 init.
 why not make it the responsibility of such hardware to do this in the init
 fn.  then the problem can be addressed without any special cases like
 !setonce.

 what do you think?


Init is probably the right place to do that, except I wouldn't
configure interfaces
I am not going to use, because, some times, they are connected to funky things
(like jtag, for example). I used open to do it on-demand. I don't know
if it was the
right decision, but that was the rationale behind it. If you think
there is a better way, proceed :-).


G.

Re: [9fans] usb serial driver

[Gorka Guardiola]

On Mon, Mar 17, 2014 at 3:35 PM, arisawa aris...@ar.aichi-u.ac.jp wrote:
 Thank you Gorka,

 I made a mistake.
 The usage of 9front is different from that of Bell-labs.
 It seems FT232R is OK, but PL2303HX has a problem.

 term% cat /lib/ndb/consoledb
 group=sys


Yes, I see. FTDI is better supported, because I had several variants
plus the device included in the Sheevaplug.

The prolific one (PL2303XXX) I had an old and slow version, so:
- New devices will probably miss stuff there was some configuration
with the H and X version.
- If the device is very fast it will probably miss bytes (there should
be buffering in the
driver like the FTDI version of it does).

Erik has seen some of these problems, maybe he has fixed them?

Fixing the driver to support the HX version sould be easy. Take a look at the
BSD driver which at the time I wrote it was the only documentation,
(this may have changed):

http://lxr.linux.no/linux/drivers/usb/serial/pl2303.c

Fixing the device missing bytes should be simple, just follow what the
FTDI version does
(use a channel with buffering).

G.

Re: [9fans] usb serial driver

[Gorka Guardiola]

Isn't it a variant of the version (almost) supported? There were sone issues at 
fast speed, but I believe it is there in the distro.


G.

 On Mar 16, 2014, at 6:40 AM, arisawa aris...@ar.aichi-u.ac.jp wrote:
 
 Hello,
 
 Anyone has a driver for FT232R or PL2303HX?
 Or working on those drivers?
 
 Kenji Arisawa
 
 

Re: [9fans] Accessing Mac OS Extended drives

[Gorka Guardiola]

This would probably make for a nice GSoC project (even if, for the purposes of
the project is a read only, without all the bells and whistles,
version of HFS+). It is documented for example here:
http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html#BTrees

On Fri, Mar 7, 2014 at 9:54 AM, Sergey Zhilkin szhil...@gmail.com wrote:
 Hello !

 Plan9 can't mount HFS or HFS+ filesystems (no fileservers :) ) but you can
 use USB disk by formatting it to a supported filesystem (fossil(4), kfs(4)).
 I think, that your Mac USB disk is labaled as UUID, and UUID is unsopported.
 Please read prep(8) for how to lebel and format disks. :)


 2014-03-07 12:44 GMT+04:00 Rubén Berenguel ru...@mostlymaths.net:

 Hi all,

 can Plan9 access a USB disk formatted with HFS plus (i.e. the Mac OS
 Extended ( journaled) file system?

 The part about USB is just because it happens to be an USB drive, but
 basically I don't know how to mount the /dev/sdD.D/data. Of course, dossrv
 can't do it (already tried).

 Thanks,

 Ruben




 --
 С наилучшими пожеланиями
 Жилкин Сергей
 With best regards
 Zhilkin Sergey



-- 
- curiosity sKilled the cat

Re: [9fans] gdbfs

[Gorka Guardiola Muzquiz]

¿Have you taken a look at the jtag tar in my contrib?
It is described here
http://lsub.org/ls/export/jtag.pdf
I don´t know enough about the RealView ICE, but if you write
the right module for whatever drives the serial communications
maybe you can drive the jtag directly.
I don´t know if that would give you anything you don´t have already
but just in case you didn´t know :-)


 On 19 Dec 2013, at 06:12, Steven Stallion sstall...@gmail.com wrote:
 
 Evening 9fans,
 
 While working on the Chromebook (nee exynos) port I ended up in a
 situation where I needed to use a more sophisticated JTAG debugger to
 find an issue. I ended up grabbing a RealView ICE since they are
 relatively cheap on eBay (around 500.00USD) compared to other models
 capable of debugging Cortex-A15 cores. Older firmware revisions of the
 RVI support the remote GDB protocol (in addition to the closed RDDI
 protocol). I've written a simple 9P file server that translates
 memory/register accesses to remote GDB targets. I haven't tried it
 yet, but this should also work with OpenOCD as well.
 
 At the moment this is little more than a toy, but it has been stable
 enough for me to debug issues on the board reliably. I've added
 support for ARM and i386 for now - adding additional register maps for
 the other mach types is straightforward. If there is enough demand,
 I'll write up a man page and submit a patch. The setup for this isn't
 particularly obvious since it requires some messing about with RVI
 firmware updates and downloading the right version of RVDS to setup
 the board, so a wiki page is deserved as well.
 
 For now, you can find the source in my contrib directory on sources:
 /n/sources/contrib/stallion/src/gdbfs/
 
 (Obligatory screenshot attached)
 
 Cheers,
 
 Steve
 gdbfs.png

Re: [9fans] 9front pegs CPU on VMware

[Gorka Guardiola Muzquiz]

 On 17 Dec 2013, at 12:00, cinap_len...@felloff.net wrote:
 
 thats a surprising result. by dog pile lock you mean the runq spinlock no?
 

I guess it depends on the HW, but I don´t find that so surprising. You are 
looping
sending messages to the coherency fabric, which gets congested as a result.
I have seen that happen.

You should back off, but sleeping for a fixed time is not a good solution 
either.
Mwait is a perfect solution in this case, there is some latency, but you are in 
a bad
place anyway and with mwait, performance does not degrade too much.

Even for user space where the spinlocks backoff sleeping,
if you get to that point, your latency goes off the roof.
Latency is worse than using mwait because you are sleeping unconditionally. 
Mwait does not prevent you from getting the interrupt to schedule.
In most cases mwait is better for performance to back off in spinlocks in 
general.
It is also good for power which may prevent cooling slowdowns of the clock too.

G.

Re: [9fans] 9front pegs CPU on VMware

[Gorka Guardiola]

 Latency is worse than using mwait because you are sleeping unconditionally.
 Mwait does not prevent you from getting the interrupt to schedule.


By this I mean that mwait unblocks on interrupt.  You could do something
like
(you do exponential backoff calling sleep or sleep/wakeup in the kernel)
one out of N where N
goes from big to 1 as the count increases:

while(1){
  mwait(l-mwaitvar);
  test_the_var_and break();
  sleep(0); //one out of N iterations
}

This will make the the process consume a little part of the quantum (until
the next tick)  waiting, and most
of that time the processor is turned off or at least consuming less.

G.

Re: [9fans] Closed nix development is an insult

[Gorka Guardiola]

On Sat, Sep 7, 2013 at 3:56 PM, Aram Hăvărneanu ara...@mgk.ro wrote:

  we got not a single cent for nix. As far as lsub is concerned,
  it's been a free time effort.

 You are seriously misrepresenting nix and/or yourself.

 From http://lsub.org:
   Nix is joint work of Laboratorio de Sistemas with Bell Laboratories,
   Sandia National Labs, and Vitanuova.

 Lsub is part of GSyC which is an academic institution funded with
 public money. Sandia National Labs is funded by the DOE. People are
 getting paid to work on nix. This is not Nemo and his friends hack
 on Plan 9 project. It that would be the case, using the lsub name
 everywhere would constitute grave academic misconduct. You publish
 papers with lsub credentials.


 My personal projects are not my employers (in fact some people place
 huge disclaimers stating that; I find the practice silly). Nix is
 not a personal project. It's listed right there on the lsub page
 along with other Plan 9-related project. Some of them even list
 their grants:

   Finnancial support, in part, by Spanish MCYT TIN2010-17344 and
   Madrid CAM S-2009/TIC-1692.

   This work is supported in part by grants CAM CLOUDS S2009/TIC-1692
   and MCyTTIN-2007-67353-C02-02

You are paid by your university to work on Plan 9-related projects.
 It's part of your everyday job.


These are projects that were funded, the work was done and published and
the code
made public.  BTW, the pressure is to patent everything and keep everything
under University IP,
and private not the other way round.

Nix today is completely unfunded and anything done is done in free time for
free,
at least on the lsub side (Erik is doing stuff with it too, and that is
funded by Coraid).

The fact that people from lsub may continue to work in Nix in their free
time does not give
you or anyone the right to anything. I am sorry if that makes you angry or
you find that
insulting.

Neither the lsub or GSyC or the University own all of its members´ free
time, and as member of
the three, we can give this free time/code to either or none.

You have no idea how much the University pays us or what part of this is
is our job, so please stop talking about what you don´t know.
If, nevertheless, you have any complaints than any of us are not doing our
jobs, please do take them
to the University (make sure you speak Spanish and have lots of time to
fill paperwork first).


 Let's take a look at other misinformation:

  Today it continues using a public development process, as described
  above.


We didn't have enough people or time to curate patches, publish them and
take care of
everything. But if you offering to sponsor us...


 It does not. It's done in secret. It wasn't always done like this.
 For a short while, development was public. It stopped being public
 when you (nemo) and Ron fighted and couldn't find common ground.
 Then you took the toys and locked them in your fortress.


Many things have happened in the past. People have their differences and
fork (nxm spanned
from that like 9front). Other times they collaborate. It is human nature.
Sometimes, as a consequence
a group working together fractures and ends up not being able to do some of
the stuff
they did.

Lsub has in the past produced much software which has been made public at
one point or the other.
We are only three people with other work to do, and we cannot maintain
infrastructure which we don´t
find useful ourselves.



  there is no private nix development going on

 Let's quote something from a recent nix paper:

   We are grateful to Charles Forsyth for his advice regarding this
   work, and to the new Plan 9 secret society.

 Ahem.


Next time we are thanking Cthulhu, it will make for better trolling.


G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

On Jun 28, 2013, at 6:27 PM, Terry Wendt silicon.pengui...@gmail.com wrote:

 I've downloaded the plan9.iso image twice from
 http://plan9.bell-labs.com/plan9/download.html
 
 Once about two weeks ago, once today.  Both times I extracted the
 plan9.iso.bz2 file to plan9.iso.  Both times I burned the image to a
 cd, and both times the program(k3b) told me the image wasn't the same
 size as the header suggests??

I'm confused. Why is the burning software looking inside the iso?

Re: [9fans] plan9 iso image

[Gorka Guardiola]

 these are two, unrelated issues.
 
 the .iso size issue should not be a big deal.  there appears to be some
 accounting that's off for cd-roms in the plan 9 iso burning software.
 (mk9660(8)).
 

Wouldn't surprise me, but it seems to work for me. If anyone has a more 
detailed explanation of what is wrong where, I'll take a look at it.
 
 this iso uses the traditional el-torito method.  unfortunately,
 the installer is size-constrained (1.44MB) and doesn't support usb.
 
 while the image
 
hget http://ftp.9atom.org/other/9atom.nboot.iso.bz2
 
 has the new installer which uses bios to access the hard drive
 without el-torito emulation, and thus has no size constraints.
 while it does fail on more hardware, it does support usb during
 the install.

I don't know much about how 9atom works, but the new plan 9 loader uses 
el-torito, but version 3 which lets you access the whole cd as an lba device.

G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom quans...@quanstro.netwrote:

  Wouldn't surprise me, but it seems to work for me.  If anyone has a
  more detailed explanation of what is wrong where, I'll take a look at
  it.

 we're now writing the nwa to disk.  this calculation appears to be
 incorrect.
 here's the check in cdfs:

 /* reconcile differing nwas */
 if (aux-mmcnwa != nwa) {
 fprint(2, %s: nwa from drive %,ld != computed nwa %,ld\n,
 argv0, aux-mmcnwa, nwa);
 fprint(2, \tbe careful!  assuming computed nwa\n);
 /* the invisible track may still start at the old nwa. */
 // aux-mmcnwa = nwa;
 }


Maybe I am not understanding. We were talking about mkisofs which generates
an iso file.
This is cdfs check for the first writable block of the track, which has to
do with burning it.
An iso is burnt inside a track and is mostly independent from the details
of what tracks exist.
Terry downloaded the iso, and tried to burn it in linux. If something is
wrong it would be
in the iso file generated, which does not have to do anything with cdfs.
G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

On Fri, Jun 28, 2013 at 7:38 PM, tlaro...@polynum.com wrote:

 On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote:
 
  this iso uses the traditional el-torito method.  unfortunately,
  the installer is size-constrained (1.44MB) and doesn't support usb.
 

 FWIW (I implemented El-Torito support for GRUB years ago), the image has
 to be some floppy size, and 2.88MB is perfectly supported.

 There is also hd emulation, but this it seems not to be widely
 supported by BIOSes.


There are various ways of booting with El-torito.

http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf

One of the ways is non-emulation (I thought it had appeared in a later
version of El-torito,
but checking the spec it was already in version 1,  1995), the byte 1 in
page
19, description in page 16.

Mkisofs lets you create a non-emulation bootable image (see
/sys/src/cmd/disk/9660/boot.c:166, which is set with -B) or an emulation
image.
Emulation goes hand in hand with pbsraw.s.

It used to be that many BIOSes did not support non-emu, but that has not
been true
AFAIK for a long while (at least more than 10 years). As long as you have
the blocks 2M aligned you should be fine with most modern BIOSes.

I think the problem is that the Plan 9 iso is somewhat different than k3b
expects
and it is fixing it, although as I said, the iso format is complex enough
and has enough
variants that there may be some error somewhere or the BIOS may have a
bug...

G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

On Fri, Jun 28, 2013 at 8:13 PM, Gorka Guardiola pau...@gmail.com wrote:




 On Fri, Jun 28, 2013 at 7:38 PM, tlaro...@polynum.com wrote:

 On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote:
 
  this iso uses the tradition

 Emulation goes hand in hand with pbsraw.s.


I mean emulation goes hand in hand with pbs.s (emulated, inside the floppy)
or pbsraw.s (non emulated,
used by the cd itself for booting).

G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

 the blocks 2M aligned you should be fine with most modern BIOSes.


I meant 2K aligned.


On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt silicon.pengui...@gmail.com
 wrote:

 If its any help, when I select 9atom.nboot.iso within K3b to burn to
 disc, it reports the filesize as 360.9 MB but the declared volume size
 as 721.7 GB.


This is very interesting because it is exactly double

  setvolsize(cd, cd-iso9660pvd, (vlong)cd-nextblock *
Blocksize);

Yes, the volume size is set here, but I don't see any at least obvious
error. Everything seems to
be counted rightly in 2K blocks. Are you pointing to an error? because I
cannot see it...

G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf

page 19:


Volume Space Size (BP 81 to 88)
This field shall specify as a 32-bit number the number of Logical Blocks in
which the Volume Space of the
volume is recorded.
This field shall be recorded according to 7.3.3.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

So... looking at the standard, the problem may be that
the volume size is in bytes instead of in blocks?

When I xd a plan 9 image (bytes are represented in little and
big endian):

0008000  01434430 30310100 504c414e 20392042
0008010  4f4f5420 49534f39 36363020 20202020
0008020  20202020 20202020 504c414e 2039202d
0008030  204d4159 20372032 30313220 32333a32
0008040  33202020 20202020  
0008050  00305600 00563000  
^^ ^^^
volume size in bytes (should this be in logical blocks?)

0008060     
0008070    0101 0101
0008080  00080800 0a00 000a c60a
^ 
Block size, 2K

0008090   0ac7  2200c20a
00080a0   0ac20010  10007005
00080b0  07151737 0002 0101 01003956


The size of the iso given by ls is 5656576, 0x00565000
which is close enough to 0x563000 in bytes.

 I xd a 90M linux iso I have and got:

0008000  01434430 30310100 4c494e55 58202020
0008010  20202020 20202020 20202020 20202020
0008020  20202020 20202020 4344524f 4d202020
0008030  20202020 20202020 20202020 20202020
0008040  20202020 20202020  
0008050  fdb3 b3fd  
 ^

90M/2K

0008060     
0008070    0101 0101
0008080  00080800 0a00 000a 1400
  ^
2K block size
0008090   0016  22001800
00080a0   00180008  08006b05
00080b0  1808100a 2002 0101 01002020

So the size should be in Blocks and it is in bytes, this is why it is wrong.

I don't understand why k3b reports double the size because it
is much more. Unless I am not seeing something...

G.






On Fri, Jun 28, 2013 at 8:57 PM, Gorka Guardiola pau...@gmail.com wrote:

 http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf

 page 19:


 Volume Space Size (BP 81 to 88)
 This field shall specify as a 32-bit number the number of Logical Blocks
 in which the Volume Space of the
 volume is recorded.
 This field shall be recorded according to 7.3.3.







-- 
- curiosity sKilled the cat

Re: [9fans] plan9 iso image

[Gorka Guardiola]

So, the proposed change would be to take out the *Blocksize from the last
parameter of setvolsize
in the calls. Can someone test it with, say... k3b and see if it improves
something?
I still don't understand why it would report a *2 difference...

G.

Re: [9fans] plan9 iso image

[Gorka Guardiola]

Agh, now I see it, I thought the units was the same, but it was actually 2K
the difference.

  360.9 MB but the declared volume size
^^^
 as 721.7 GB.
^^^

So all is explained.
Ok, I'll create a patch.

G.



On Fri, Jun 28, 2013 at 10:13 PM, Gorka Guardiola pau...@gmail.com wrote:


 So, the proposed change would be to take out the *Blocksize from the last
 parameter of setvolsize
 in the calls. Can someone test it with, say... k3b and see if it improves
 something?
 I still don't understand why it would report a *2 difference...

 G.




-- 
- curiosity sKilled the cat

Re: [9fans] plan9 iso image

[Gorka Guardiola]

I created the patch mkisovolsize.

G.

Re: [9fans] plan9 iso image cont.

[Gorka Guardiola]

On Fri, Jun 28, 2013 at 11:26 PM, Terry Wendt
silicon.pengui...@gmail.comwrote:

 K3b actually said 721.7 GB. As in Gigabytes.



Yes, 720GB/360MB is 2K. The size complains are fixed by my patch.
I can't generate an image now, but that problem should be fixed for the
future.
In any case, I don't think it affects the images you burnt with brasero at
least.




 So, I've downloaded, burned, and tried to install the following iso images:

 9front-2688.28a9914426a3.iso (I used Brasero to burn the cd, no size
 complaints)
 +9atom.iso
 9atom.iso
 9atom.nboot.iso
 plan9.iso

 None actually booted, but some got farther then others.

 Results:

 plan9.iso - PBSR...EI  as far as it got and froze


This is an error reported by the bios. This does not have to do with the
other error. This has to do with something bad happening when the BIOS
is accessing the drive. My guess is the BIOS is buggy, the cd is wrong
(physically)
or the reader is wrong, but it may be some bug interacting with the
hardware.


 9front.iso


I don't know much about about 9atom or 9front, but they are quite different
from
plan9 in the way it boots. Other people are more qualified than me to answer
questions about both.



 I burned all the iso images with K3b, with the exception of 9front. I
 used brasero for that and brasero did not complain about file size and
 volume size not matching.  However, when I open 9front up in K3b, it
 does complain that the filesize is 530.9 MiB, while the volume size is
 reported as 1 TiB.


This is again 1TB/530MB - 2K, so mkisofs is the most probable culprit,
but again, this should not affect the booting.




 Gorka - The reason I asked about whether or not I should be unzipping
 the iso is the plan9 install instruction have a line thus:
 boot from: sdC1!cdboot!9pcflop.gz
 I realize that's probably a floppy sized gzipped boot image on the cd,


This is the compressed kernel inside the image.


 Anyway, next steps?


 I would recommend either a virtual machine like Bakul says or, if possible
change the CD drive. You could try also booting from USB, I don't know
if there are any usb images laying around...

G.

Re: [9fans] Installing Go

[Gorka Guardiola]

Sorry, you also need to get the tip (use hg to get the
latest without saying you want a release)
In arm you will need lucio´s patch.


On Fri, May 17, 2013 at 12:32 AM, Gorka Guardiola pau...@gmail.com wrote:

 You have a script called all.rc which does the work.

 G.



 On Fri, May 17, 2013 at 12:31 AM, lamg gort.andres...@gmail.com wrote:

  Anyone has installed Go, the source code has Makefiles and bash
 scripts for building, it doesn´t seem to be for plan9.




 --
 - curiosity sKilled the cat




-- 
- curiosity sKilled the cat

Re: [9fans] Installing Go

[Gorka Guardiola]

You have a script called all.rc which does the work.

G.



On Fri, May 17, 2013 at 12:31 AM, lamg gort.andres...@gmail.com wrote:

  Anyone has installed Go, the source code has Makefiles and bash
 scripts for building, it doesn´t seem to be for plan9.




-- 
- curiosity sKilled the cat

Re: [9fans] vncv sw cursor trail

[Gorka Guardiola]

On Tue, May 7, 2013 at 4:10 PM, erik quanstrom quans...@quanstro.netwrote:

 On Tue May  7 05:03:57 EDT 2013, yari...@gmail.com wrote:
  When using vncv on a terminal with software cursor (vesa, rpi) the
  mouse cursor leaves a trail.  This seem to be caused by the fact that
  vncv loads picture updates with loadimage(2) directly to screen.
  Loading to an offscreen image followed by a draw(2) to screen removes
  the artifact:

 i'm not convinced this fix gets at the real issue.  (and allocating
 new images might amplify latency.)


 This problem happens in 386 too (I mean the original
problem this patch is addressing or tries to address).
G.

Re: [9fans] Go Plan9 ARM Dreamplug

[Gorka Guardiola]

This is a known problem with 5c. It cannot switch on vlong. As a stopgap,
you can
change the types of the things being switched on to integer (type, if I
remember right).

G.



On Mon, Apr 15, 2013 at 9:00 AM, Christopher Nielsen cniel...@pobox.comwrote:

 After a little work, I have a Plan 9 dev environment setup. My dreamplug
 boots with no problems, and after installing python and mercurial, I was
 able to clone the go repo. The build completes fine on 386, but on the
 dreamplug I get the errors below. Yes, I know I should probably be running
 as a user other than bootes; this was a quick and dirty install to get
 things running. Also, opnames.h does exist.

 dreamplug# ls -l /usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h
 --rw-rw-r-- M 15 bootes bootes 3273 Apr 15 02:47
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h

 Also, it doesn't look like the tests are being run on 386. Forgive my
 ignorance, but is that currently intentional?* *I haven't had time to
 search the list.

 cmd/gc
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/reflect.c:1022[/usr/bootes/src/go-plan9-arm/src/cmd/gc/reflect.c:3400]
 switch expression must be integer
 go tool dist: FAILED: /bin/5c -FTVw -Bp+
 -I/usr/bootes/src/go-plan9-arm/include/plan9
 -I/usr/bootes/src/go-plan9-arm/include/plan9/arm -I
 /usr/bootes/src/go-plan9-arm/src/cmd/gc -o $WORK/reflect.5
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/reflect.c:
 '/usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h' does not exist
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:665[/usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:3240]
 switch expression must be integer
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:2863[/usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:5373]
 switch expression must be integer
 warning:
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:2846[/usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:5356]
 used and not set: fn
 go tool dist: FAILED: /bin/5c -FTVw -Bp+
 -I/usr/bootes/src/go-plan9-arm/include/plan9
 -I/usr/bootes/src/go-plan9-arm/include/plan9/arm -I
 /usr/bootes/src/go-plan9-arm/src/cmd/gc -o $WORK/subr.5
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:
 '/usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h' does not exist

 --
 Christopher Nielsen
 They who can give up essential liberty for temporary safety, deserve
 neither liberty nor safety. --Benjamin Franklin
 The tree of liberty must be refreshed from time to time with the blood of
 patriots  tyrants. --Thomas Jefferson




-- 
- curiosity sKilled the cat

Re: [9fans] Go Plan9 ARM Dreamplug

[Gorka Guardiola]

1) if you don't change the type of type to be int, it will give you bogus
errors, but
the real problem is that some of the files do not compile.

2) opnames.h is autogenerated by dist. IIRC there is no problem with it
(see 1).

3) I have GOEXPERIM set to ''. You need to set a ton of variables, out of
the top of my head,
assuming you are not cross-compiling:


GOROOT=/sys/src/golang #where the go repository resides
GOOS=plan9
GOARCH=$objtype
GOHOSTARCH=$cputype
GOBIN=/$objtype/bin
GOPATH=/sys/src/go #wher your go stuff resides
GOARM=5 #or 6 or 7, depending on your machine's support of floating point.
GOEXPERIM=''






On Mon, Apr 15, 2013 at 10:22 AM, Skip Tavakkolian 
skip.tavakkol...@gmail.com wrote:

 I'm getting something similar on Sheeva. It also looks like there are
 still env issues:

 sheeva% ./all.rc
 # Building C bootstrap tool.
 cmd/dist

 # Building compilers and Go bootstrap tool for host, plan9/arm.
 lib9
 libbio
 libmach
 misc/pprof
 cmd/addr2line
 cmd/cov
 cmd/nm
 cmd/objdump
 cmd/pack
 cmd/prof
 cmd/cc
 warning:
 /usr/fst/Go1/src/cmd/cc/y.tab.c:1733[/usr/fst/Go1/src/cmd/cc/y.tab.c:3416]
 result of operation not used
 warning:
 /usr/fst/Go1/src/cmd/cc/y.tab.c:1733[/usr/fst/Go1/src/cmd/cc/y.tab.c:3416]
 result of operation not used
 warning:
 /usr/fst/Go1/src/cmd/cc/y.tab.c:1736[/usr/fst/Go1/src/cmd/cc/y.tab.c:3419]
 set and not used: yymsg
 warning:
 /usr/fst/Go1/src/cmd/cc/y.tab.c:1924[/usr/fst/Go1/src/cmd/cc/y.tab.c:3595]
 set and not used: yyptr
 cmd/gc
 /usr/fst/Go1/src/cmd/gc/reflect.c:1022[/usr/fst/Go1/src/cmd/gc/reflect.c:3400]
 switch expression must be integer
 go tool dist: FAILED: /bin/5c -FTVw -Bp+ -I/usr/fst/Go1/include/plan9
 -I/usr/fst/Go1/include/plan9/arm -I /usr/fst/Go1/src/cmd/gc -o
 $WORK/reflect.5 /usr/fst/Go1/src/cmd/gc/reflect.c: '/env/GOEXPERIMENT' file
 does not exist
 /usr/fst/Go1/src/cmd/gc/subr.c:665[/usr/fst/Go1/src/cmd/gc/subr.c:3240]
 switch expression must be integer
 /usr/fst/Go1/src/cmd/gc/subr.c:2863[/usr/fst/Go1/src/cmd/gc/subr.c:5373]
 switch expression must be integer
 warning:
 /usr/fst/Go1/src/cmd/gc/subr.c:2846[/usr/fst/Go1/src/cmd/gc/subr.c:5356]
 used and not set: fn
 go tool dist: FAILED: /bin/5c -FTVw -Bp+ -I/usr/fst/Go1/include/plan9
 -I/usr/fst/Go1/include/plan9/arm -I /usr/fst/Go1/src/cmd/gc -o $WORK/subr.5
 /usr/fst/Go1/src/cmd/gc/subr.c: '/env/GOEXPERIMENT' file does not exist
 sheeva%



 On Mon, Apr 15, 2013 at 1:12 AM, Christopher Nielsen 
 cniel...@pobox.comwrote:

 I'll give that a shot and see if I get different results. It'll have to
 be some time tomorrow though. What concerns me is that the error says it
 can't find opnames.h when it clearly exists.


 On Mon, Apr 15, 2013 at 12:08 AM, Gorka Guardiola pau...@gmail.comwrote:

 This is a known problem with 5c. It cannot switch on vlong. As a
 stopgap, you can
 change the types of the things being switched on to integer (type, if I
 remember right).

 G.



 On Mon, Apr 15, 2013 at 9:00 AM, Christopher Nielsen cniel...@pobox.com
  wrote:

 After a little work, I have a Plan 9 dev environment setup. My
 dreamplug boots with no problems, and after installing python and
 mercurial, I was able to clone the go repo. The build completes fine on
 386, but on the dreamplug I get the errors below. Yes, I know I should
 probably be running as a user other than bootes; this was a quick and dirty
 install to get things running. Also, opnames.h does exist.

 dreamplug# ls -l /usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h
 --rw-rw-r-- M 15 bootes bootes 3273 Apr 15 02:47
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h

 Also, it doesn't look like the tests are being run on 386. Forgive my
 ignorance, but is that currently intentional?* *I haven't had time to
 search the list.

 cmd/gc
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/reflect.c:1022[/usr/bootes/src/go-plan9-arm/src/cmd/gc/reflect.c:3400]
 switch expression must be integer
 go tool dist: FAILED: /bin/5c -FTVw -Bp+
 -I/usr/bootes/src/go-plan9-arm/include/plan9
 -I/usr/bootes/src/go-plan9-arm/include/plan9/arm -I
 /usr/bootes/src/go-plan9-arm/src/cmd/gc -o $WORK/reflect.5
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/reflect.c:
 '/usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h' does not exist
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:665[/usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:3240]
 switch expression must be integer
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:2863[/usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:5373]
 switch expression must be integer
 warning:
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:2846[/usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:5356]
 used and not set: fn
 go tool dist: FAILED: /bin/5c -FTVw -Bp+
 -I/usr/bootes/src/go-plan9-arm/include/plan9
 -I/usr/bootes/src/go-plan9-arm/include/plan9/arm -I
 /usr/bootes/src/go-plan9-arm/src/cmd/gc -o $WORK/subr.5
 /usr/bootes/src/go-plan9-arm/src/cmd/gc/subr.c:
 '/usr/bootes/src/go-plan9-arm/src/cmd/gc/opnames.h' does not exist

 --
 Christopher Nielsen

Re: [9fans] Go Plan9 ARM Dreamplug

[Gorka Guardiola]

On Mon, Apr 15, 2013 at 10:31 AM, kernel panic cinap_len...@gmx.de wrote:

 go is using switch on vlongs. support for this was backported to plan9 c
 compiler
 some time ago. just update the compilers from sources.


 Last time I checked (like a week ago) it did not work with 5c.

G.

Re: [9fans] mk and transitive dependencies (was: gcc not an option for Plan9)

[Gorka Guardiola]

 anybody care to explain what is the limitation of mk here? can't wrap my head 
 around it...

It only knows about the rules you give it. It does not understand the real 
dependencies in your software.
Also, because of this you tend to give it general rules which are not always 
right.
There are more, but these are the ones Rob was referring to, I think.

(Just in case, I am not making a point for or against mk, just trying to answer 
his question)

G.

Re: [9fans] mk and transitive dependencies (was: gcc not an option for Plan9)

[Gorka Guardiola]

On Mar 25, 2013, at 11:33 AM, hiro 23h...@gmail.com wrote:
 
 what does understand mean in that context?
 I would think if this is all done automagically with go it would need
 to follow even more general rules, no?

No, they are concrete and specialized for go (the language). Go (the tool)
knows about the different ways the go program can be compiled, how the imports 
work, etc. and deduces what to do from that.

The general rules in mk are more everytime you see a file ending like this, do 
that.

G.

Re: [9fans] mk and transitive dependencies (was: gcc not an option for Plan9)

[Gorka Guardiola]

On Mar 25, 2013, at 11:40 AM, Bence Fábián beg...@gmail.com wrote:

 mk doesn't parses '#include' directives in C and even if it did, it wouldn't 
 help.
 I think that's what hes referring to.

Yes.

Re: [9fans] gcc not an option for Plan9

[Gorka Guardiola]

 Binaries are one order of magnitude larger and the go tool  part of the 
 runtime code are, well….
 
 sorry to be dense.  larger than what?

C

Re: [9fans] gcc not an option for Plan9

[Gorka Guardiola]

 
 ah.  i thought you were saying that it was an order of magnitude
 larger than the unix version of go.
 
 by the way, does this scale with lines of go code, or is it just
 that the trivial go executable is megs?

A simple hello world is megs.

G.

Re: [9fans] gcc not an option for Plan9

[Gorka Guardiola]

On Sat, Mar 23, 2013 at 6:15 PM, Rob Pike robp...@gmail.com wrote:
 Much of which is symbols. Plus, a a simple computer has gigs of memory.

 Yes, it's remarkable how much bigger programs are now than they were
 20 years ago, but 20 years ago the same things were being said. I
 understand your objection - I really do - but it's time to face the
 future. The smart phone in your pocket is roughly 100 times faster
 than the machine Plan 9 was developed on and has 1000 times the RAM.

I was merely stating facts, not criticising, as I am still learning about the go
implementation, and I am sure there are good reasons why all this is true.
In any case, the argument that there is more memory now is not a very good one
unless you use it for something useful. The phone is very powerful, but
it also runs on a battery and has to do many things on a budget, so that
is not really an argument. Saying why you need/use the giant tables for
may be.


- With greater power comes greater need for restrain.

G.

Re: [9fans] gcc not an option for Plan9

[Gorka Guardiola]

On Sat, Mar 23, 2013 at 8:23 PM, ron minnich rminn...@gmail.com wrote:
 I'll happily pay the price of bigger binaries for things such as the %v 
 format.

 I don't write hello, world that often, or even care about its size when I do.

Hello world was just an example, please don't make a straw man out of it.
If you want real programs which are bigger that I (we) actually use that will
be (much) bigger in go:

ls, cp rm mv cat acid, I can go on.

Small programs are useful and important.

There is a price to pay, and if you get something useful out of it, it may be
a fair price to pay, as I said in my other e-mail, I was just stating
a fact, binaries
are bigger and for example replacing the minimal sets of commands of
the system, this can make the
minimal system at least 5 times bigger easy.


 I have  a hard time worrying about 1M binaries on $200 machines with
 12 GB/s memory bandwidth and 4G memory.
 It's 2013.


A lot of my friends have cheap phones that run out of memory
all the time. There is not a one size fits all in engineering, there
are compromises
and uses.

Higher level programming means paying the cost of bigger binaries,
that may be ok
for some uses and not for others. I like writing go code, it is fun, and
has a fairly high level of abstraction while letting you access the
system easily
(I am looking at you Java).

As I said, at least from me, it was not a complaint, just a statement of a fact.
I have spent quite some amount of time lately getting go working on
arm in Plan 9
because I value the language.

G.

Re: [9fans] usb serial

[Gorka Guardiola]

 typing doesn't work at all.
 
 before i go charging off learning about the prolific serial,
 has anyone gone a round or two with this type of hardware?
 any clues on what i should be looking for?

I have one which I used to write the code and used as my sole console to the 
machine I was debugging for everyday like 3 months. Then I got a new one and I 
stopped using it. Some weeks ago Jeff complained about it and Richard and I 
concurrently found a bug in it. I tested it very lightly and it seemed to work. 
I think that because noone is using it daily changes are not tested in it.

Are you using the version from sources? I'll get out my dongle and test it 
again (no pun intended).

G.

Re: [9fans] Can you pass the Advanced Namespace Test?

[Gorka Guardiola]

 
 This is something you will have to get used to. Ideas, whether
 good or bad, usually take a very long time to attract much attention.

Indeed. Take the pleasure from making cool stuff. Eventually someone will 
notice (or not). But if you had fun while doing it, it was worth it.

G.

Re: [9fans] cold boot installation of Plan 9 on a eeepc 701 :(

[Gorka Guardiola]

On Feb 21, 2013, at 2:49 PM, erik quanstrom quans...@quanstro.net wrote:

 iirc, 9boot doesn't use floppy emulation, but
 it might then need cdfs.  i haven't tried this,
 so someone who has should speak up.  :-)

It does not have a floppy. You do not need cdfs for loading.
The mbr is in the first sector like in a hard disk and it is anotated
where the 9load is
when creating the filesystem.

There is a 9fat file in the iso called bootdisk.img in the root
directory. The loader knows enough to get to it,
and then gets the kernel.

G.

Re: [9fans] multi-processor support

[Gorka Guardiola]

Have you ticked?

Enable the IO APIC

Re: [9fans] usb serial bug

[Gorka Guardiola]

Yes, I am looking into it and just saw this.
G.

On Feb 14, 2013, at 8:24 PM, Richard Miller 9f...@hamnavoe.com wrote:

 I said:
 
 The current Plan 9 usb architecture perpetuates the confusion by
 referring to them both with one name epN.1, but you still have to open
 them both independently.
 
 Erik replied:
 in that case, shouldn't these three blocks be reverted?
 
 Erik is right, I was talking through my hat.  It's OK to open bulk
 endpoints read/write, and the kernel will do the right thing.  The
 actual problem, which neither of us had spotted although it was
 staring us in the face, is this:
 
if((ep-dir == Ein || ep-dir == Eboth)  epin == -1)
epin = ep-id;
if((ep-dir == Ein || ep-dir == Eboth)  epout == -1)
epout = ep-id;
 
 Notice the two occurrences of Ein?  The second one obviously should
 be Eout.  It was a typo (mine, I blush to admit).
 
 My usb serial adapter uses the same ep number for input and output,
 so my testing didn't reveal this error.  I think the same typo will
 account for the double-free bug which Jeff (and Lucio on 4 Feb) reported.
 
 Erik, Jeff, Lucio - please try changing the offending Ein to Eout in 
 /sys/src/cmd/usb/serial/serial.c:721 and see if your troubles are resolved.
 
 

Re: [9fans] usb serial bug

[Gorka Guardiola]

With the Ein fix, it works again with the
Trendnet TU-S9 which reports:
vid 0x067b
did 0x2303
which is prolific.
G.

Re: [9fans] acid on linux; easiest-to-set-up virtual machine

[Gorka Guardiola]

In the standard plan 9, e820 scan. When disabled, a vesa bug which 9front 
circunvents with realemu.


On Jan 25, 2013, at 8:46 PM, James Chapman ja...@cs.ioc.ee wrote:

 It hangs during booting.
 
 The same as this I think:
 
 https://forums.virtualbox.org/viewtopic.php?f=4t=52431
 
 
 On Jan 25, 2013, at 9:15 PM, cinap_len...@gmx.de wrote:
 
 whats the problem with this version?
 
 --
 cinap
 
 

Re: [9fans] Spanish hyphenation in troff

[Gorka Guardiola]

On Fri, Jan 18, 2013 at 3:14 PM, trebol trebol55...@yahoo.es wrote:
 Thanks Gorka, but I've tried that with
 ftp.ctan.org/pub/tex/language/hyphenation/eshyph.tex
 and all I've is:

 assertion failed: file n8.c:543

 I'm new to plan9, so I'm a little lost.  Sorry if this is an
 obvious/common task.

 trebol.


Looking at the version on our tree, there was a fix for this, but to
me it seems wrong.
The function trieindex (and maybe the whole implementation of hyphenation) looks
ascii-centric and most probably needs reimplementation. I may be
wrong, though, as
I am unfamiliar with the code.

G.

Re: [9fans] Spanish hyphenation in troff

[Gorka Guardiola]

In other words, forget my previous recommendation, hyphenation only seems
to work for ascii.
Or, alternatively, this is an opportunity for you to reimplement n8.c
for UTF8 support.


G.

Re: [9fans] build iso's plan9 for amd64, atom, arm, powerpc

[Gorka Guardiola]

On Wed, Jan 2, 2013 at 9:11 PM, John Floren j...@jfloren.net wrote:
 What I think people are trying to say is that this doesn't really make
 a lot of sense. The AMD64 system doesn't have any installer work done
 for it at all--I think it's not far off, but to the best of my
 knowledge nobody has built a CDROM that boots the 64-bit kernel and

I did boot nix with the new boot loaders from a CD image, so that part
worked. Erik is using a different boot loader I think, but it probably works too
(it boot in 32 bit mode after all...).

After booting the kernel, as Erik says, it should not be too hard.

For ARM Richard Miller is doing an excellent work with his prerrolled
Plan 9 images for the raspberry pi, so that is probably the way to go.

G.

Re: [9fans] build iso's plan9 for amd64, atom, arm, powerpc

[Gorka Guardiola]

 (it boot in 32 bit mode after all...).


Actually 16 bit mode...

Re: [9fans] file server design documentation

[Gorka Guardiola]

I normally use a combination of running iostats and ramfs with debugging and 
reading again and again intro(5).

HTH. 

G.

On Dec 21, 2012, at 7:23 PM, steve st...@quintile.net wrote:

 hi,
 
 I writing another non-disc file server after a gap of a few years
 and am making mistakes.
 
 is there a written spec of how its supposed to work?
 
 For example:
 
 the initial stat of a zero length name should return the Dir
 of the root dir.
 
 and a walk up to the root directory tells mount driver that
 you want to pass control back to the parent filesystem.
 
 -Steve
 
 

Re: [9fans] Logitech m310 mouse issues

[Gorka Guardiola]

On Dec 7, 2012, at 1:37 PM, Richard Miller 9f...@hamnavoe.com wrote:

 I think the problem may be incorrect handling of the default boot protocol
 for the usb mouse.  If so, I have a new kernel which should fix it.  Please
 could you try this:

By your previous description it is not really the boot protocol.
Like a year ago we got some new mice for which the boot protocol would hang 
after a while, so I bit the bullet and wrote a parser for the report descriptor.
So the usb mouse is not using the boot
protocol by default any more.

This sounds like a bug either in the descriptor or in the parser, so yes, maybe 
just forcing the boot protocol might fix it.

Someone reported another problem too and I have the bug report waiting for me 
to have some time to look into it. This may be related. I haven't encountered 
any problem myself and I have tried in like a 50 mice :-S.

G.

Re: [9fans] C++

[Gorka Guardiola]

On Thu, Nov 22, 2012 at 11:32 PM, Winston Kodogo kod...@gmail.com wrote:

 But, let the record show, C++ has been scientifically shown to be an
 unbelievably crap and monstrously complex language, even though I earn
 my daily bread by using it. I was a contemporary of Dr Stroustrup when
 he was spending his time dragging the Cambridge mainframe to its knees
 using the Simula compiler - the kindest description I ever heard from
 friends in the computer lab was stubborn-  and occasionally, ok
 frequently, or indeed always, am tempted to view C++ as his revenge on
 the world for pointing out that he doesn't have a clue how to program
 efficiently.


Yes, this is why most games, which do not need speed or efficiency at all
are programmed in C++. I don't like C++, but it is a tool and as such, it
has shown it is useful in some environments. Is it aesthetically pleasant?
no. Is it more complex than needed? yes. But claiming that it is not possible
to program efficiently in C++ (or implying so) is going into religious grounds
and negating reality.

BTW, making ad-hominem attacks against a language author says more
about you than the language itself.


G.

Re: [9fans] iwp9 2013

[Gorka Guardiola]

On Wed, Nov 21, 2012 at 10:14 AM, Brantley Coile brant...@coraid.com wrote:
 Or from the seventh floor of our 100+ year old building.


Is that considered old? I mean my house is 100+ year old, but I
consider it newish. I guess it depends on the continent :-).

G.

Re: [9fans] rc vs sh

[Gorka Guardiola]

On Oct 25, 2012, at 5:08 PM, hiro 23h...@gmail.com wrote:

 can someone tell me how to speed up poweroff on ubuntu?

Pull the cable and or battery.

G.

Re: [9fans] usbether

[Gorka Guardiola]

On Sat, Sep 29, 2012 at 6:16 PM, Richard Miller 9f...@hamnavoe.com wrote:
 So, has anyone had success using usbether to connect a plan 9 system
 to the outside world?  I am hoping someone can give me an encouraging
 report.  I'm a bit worried that it's a fundamental problem with the
 plan 9 usb architecture, which is basically synchronous - the host
 adapter driver in the kernel will poll a device for input only when
 the user-level driver process does a read.  This is ok for things like
 usbdisk which have an rpc-like protocol, but seems less well suited to
 things like ethernet and serial interfaces, where the equivalent
 non-usb kernel drivers use qio to read ahead into a queue of buffers
 until the user-level consuming process gets around to reading them.

 Would anyone like to share experiences or comments?



I had a similar problem with serial a while ago. The problem was that
it was taking too long doing too many system calls, doing big reads
and buffering may help you?

G.

Re: [9fans] usbether

[Gorka Guardiola]

On Sat, Sep 29, 2012 at 8:01 PM, Richard Miller 9f...@hamnavoe.com wrote:

 Almost: it's a pipeline of one thread reading a buffer full of packets,
 splitting it up, and sending a packet at a time to a second thread, which
 writes them to the kernel packet ethernet interface, which stores them
 in a Buf queue.


Taking a cursory glance it looks as if it just reading at most one
full packet at a time
(the size of the buffer is 2000), it may be if they are small you may
get more than one
in one read, but it may not be so, depends on the device and what is
set as maxpkt
which may be changed with usbctl if the device lets you

Making a bigger buffer (after making sure you can actually read more
bytes) and or decoupling
reader and processer by having a buffered channel so that the
reader can spend more time reading may help (it helped for serial).


G.

Re: [9fans] usbether

[Gorka Guardiola]

On 29/09/2012, at 23:25, Richard Miller 9f...@hamnavoe.com wrote:


That's the asix driver: the raspberry pi adapter has an SMSC LAN95xx,
see /n/sources/contrib/miller/usb/ether/smsc.c for my driver which
reads up to 37*512=18944 bytes at a time.


And is it really doing it? I mean it asks for many bytes but how many
does it get?

G.

Re: [9fans] tcp!

[Gorka Guardiola]

I had this problem several years ago
with an adsl router (9fans archive may know about this). There was a bug in my 
adsl router (which seems to be common, I have seen it since more than once) 
that dropped ethernet frames of size greater than 1480 (someone counted a 
header twice probably). Linux adapts the
mss to 1480 if there are problems so it works in this case. 

G.

On Aug 21, 2012, at 8:32 PM, Richard Miller 9f...@hamnavoe.com wrote:

 I reported:
 
 Within the last month or so I've been having trouble copying large
 files to remote servers e.g. sources.  The cp process hangs for
 many minutes and eventually ends in 'mount rpc error'.
 
 Thanks to a hint from Erik (... an mss problem of some sort), I've
 managed to make the problem go away, by doing
  echo mtu 1496 /net/ipifc/1/ctl
 
 I hope to come back to this when I have more time, because I don't
 like not understanding why this works.  As nobody else has said they
 have the same trouble, there may be something amiss in my adsl gateway.
 
 

[9fans] empty *

[Gorka Guardiola]

While playing with grep, I was suprised by grep '*\.c' not giving
an error (* is missing an operand). Arguably * applied to empty
can match empty, but surprisingly enough, Acme's edit behaves
differently. And even grep is not consistent (grep '*' is different than
grep '' whereas both should be an empty pattern or the first one
should be an error). Another funny one is that Edit gives back
an error complaining of missing operand to * when the regexp is
empty.

Greps from other systems accept an empty pattern
(and are thus consistent but they would not have
catched the error starting all this).


cpu% echo hola | grep '*a'
hola
cpu%  echo hola | grep '*'
grep: *: syntax error
cpu%  echo hola | grep ''
grep: empty pattern

Edit , s/*//
regexp: missing operand for *
Edit: bad regexp in s command

Edit , s/*c//
regexp: missing operand for *
Edit: bad regexp in s command

Edit , s///

regexp: missing operand for *
Edit: bad regexp in s command

G.

Re: [9fans] empty *

[Gorka Guardiola]

On Thu, Jun 14, 2012 at 11:32 AM, Peter A. Cejchan tyap...@gmail.com wrote:
 This is from manpage, but I not sure what _exactly_ it means, and whether it
 applies to your problem:
   Care should be taken when using the shell metacharacters
   $*[^|()=\ and newline in pattern; it is safest to enclose
   the entire expression in single quotes '...'.  An expression
   starting with '*' will treat the rest of the expression as
   literal characters.


Everything is enclosed in '' the shell is not seeing this.

G.

Re: [9fans] empty *

[Gorka Guardiola]

On Thu, Jun 14, 2012 at 3:33 PM, erik quanstrom
quans...@labs.coraid.com wrote:
 On Thu Jun 14 04:29:51 EDT 2012, pau...@gmail.com wrote:
 While playing with grep, I was suprised by grep '*\.c' not giving
 an error (* is missing an operand). Arguably * applied to empty

 nope, that's not right.  * starting a pattern escapes the whole string.
 this is unique to grep.


Argh, yes, it has a special meaning. I have somehow managed to miss
this for all this time.

G.

Re: [9fans] empty *

[Gorka Guardiola]

On Thu, Jun 14, 2012 at 4:00 PM,  tlaro...@polynum.com wrote:
 On Thu, Jun 14, 2012 at 09:44:25AM -0400, erik quanstrom wrote:
   nope, that's not right.  * starting a pattern escapes the whole string.
   this is unique to grep.

 I guess this is surprising because with a POSIX grep(1), if I read the
 description correctly:

 1) If the * is the very character of a BRE (since POSIX has BRE and ERE)
 it shall be treated as is---but the remaining of the expression is
 interpreted.

 2) In a ERE, if the * is the very first character, or follows |,
 ^ or ( this is undefined.

Also this:

cpu%  echo hola | grep '*'
grep: *: syntax error
cpu%  echo hola | grep ''
grep: empty pattern


grep '*' and grep '' should still be the same, shouldn't they?

G.

Re: [9fans] empty *

[Gorka Guardiola]

On Thu, Jun 14, 2012 at 4:46 PM, erik quanstrom
quans...@labs.coraid.com wrote:
 cpu%  echo hola | grep '*'
 grep: *: syntax error
 cpu%  echo hola | grep ''
 grep: empty pattern


 grep '*' and grep '' should still be the same, shouldn't they?

 yes, but does it matter?

Probably not.

G.

Re: [9fans] Heresy alert, Zerox - Clone

[Gorka Guardiola]

 Yes, which makes one wonder about type systems in programming languages and
 if they're any better than documented conventions of I/O.  (i think they may
 not be, but they serve some documentation purposes all their own)


I think type systems have their use but do not help much at the borders
(I/O) of the program.

Reminds me of this paragraph in our paper (sorry for the autoquote)

http://www.mdpi.com/1424-8220/12/6/7109

The most usual mistake is to argue that synthetic files do not provide
types and/or type checking, for example, when used to execute commands
or to exchange data represented as text. It may not seem so, but type-checking
does not help much regarding correctness of the requests made and/or
data retrieved.
Note that clients and servers may be written in different programming
languages.
Some will be strongly typed, some not. Those that are typed may have
different, incompatible, type systems.
Synthetic file servers must check data written for validity, like an OS
kernel or a network server would. If the request made is invalid, an error
is raised. It does not really matter in practice if the error is due
to type checking
or due to an invalid request. If the response given by a server is not
correct, the
client of the server is responsible for checking it for validity and
acting accordingly.
What we have seen in practice, if that when the user makes a mistake, the device
raises an error, and the user tries again; this has never turned out
to be a problem.

Re: [9fans] rc behavior with rfork

[Gorka Guardiola]

 On the otherhand, putting any command in the chain makes the behavior
 disappear.

 cpu% @{rfork e; echo hi} |cat  /env/hi cpu% cat /env/hi hi

 My question is, is this intensional?  It feels as if there is a
 leakage here of the rfork when its effect is felt beyond the braces,
 and it feels odd for the two fs interfaces to behave differently (even
 though one of them is special)


When the subshell executes the rfork, how is it to know that the /env is
outside of the braces?

Another way of asking it is:

if I have a program with an open file descriptor in /env and calls rfork RFENVG
what should happen with its /env?

That program is the shell and any command it executes that inherits
the file descriptor.

G.

Re: [9fans] Governance question???

[Gorka Guardiola]

On Wed, May 16, 2012 at 2:30 AM,  kokam...@hera.eonet.ne.jp wrote:
 but refers to the Latin motto Nemo me impune lacessit!

 Sorry, off topis.
 What does this Latin motto mean?
 I have no Latin based culture...

 Kenji -- still learning octopus and inferno☺



It means (loosely translated) no-one provokes me without punishment.

http://en.wikipedia.org/wiki/Nemo_me_impune_lacessit

Famous for Edgar Allan Poe's The Cask of Amontillado story
and being on the side of a pound coin.
http://static.twoday.net/mahalanobis/images/pound1984.jpg

G.

Re: [9fans] Governance question???

[Gorka Guardiola]

2012/5/14 Bruce Ellis bruce.el...@gmail.com:
 Ah - Bund Deutscher Fußball-Lehrer - of course!


Nein, british defense film library.

G.

Re: [9fans] Summary of acme chords

[Gorka Guardiola]

On Wed, Apr 25, 2012 at 9:34 PM, andrey mirtchovski
mirtchov...@gmail.com wrote:
  http://alltom.com/files/misc/chords.png

 a suggestion?

 http://i.imgur.com/hjFJa.png


I really like this graphics and with the text they are even
better.

G.

Re: [9fans] AMD64 system

[Gorka Guardiola]

 The main one is this: I have a 64-bit machine, and I'll be damned if
 my programs won't use every last one of them (^_~)


We are going to be grateful to you saving yourself by writing
drivers...

G.

Re: [9fans] fossil deadlock

[Gorka Guardiola]

On Mar 22, 2012, at 12:57 PM, Richard Miller 9f...@hamnavoe.com wrote:

 Thanks to detective work by Rod at hemiola and David du Colombier,
 I've been able to find  fix the long-standing deadlock in fossil's
 snapshot code.
 
 Patch is fossil-snap-deadlock.

Kudos to you all!!

G.

Re: [9fans] known working wifi cards

[Gorka Guardiola]

 thinking about patching a Linux driver module to record everything it
 does and every command it receives; snooping with driver help.


Wireshark can snoop usb traffic. It is easy and gives you all the
information you
probably need.

There is also a similar thing for windows. Can't remember the name.

G.

Re: [9fans] usb/wacom

[Gorka Guardiola]

On Feb 29, 2012, at 4:32 AM, Tristan 9p...@imu.li wrote:

 
 oh, and you'll need to somehow inhibit kb from automatically managing it.
 (and as kb doesn't understand so called report numbers...)

This is most probably my fault.
I did cut some corners trying not
to implemenent a generic report
parser
Tell me in as much detail offlist
as you can and I'll try to fix it.

G.

Re: [9fans] p9p troff/ps problem, comparison with heirloom

[Gorka Guardiola]

On Nov 11, 2011, at 8:06 PM, Rudolf Sykora rudolf.syk...@gmail.com wrote:
 screen prints wrongly. Furthermore, now page displays different things
 than gv.
 
 I hoped that with postscript one can achieve the same results
 everywhere, but it actually seems difficult...

When this happens to me, normally it is because I did not download the fonts 
into the document.

See:

http://plan9.bell-labs.com/wiki/plan9/fonts/index.html

HTH

G.

Re: [9fans] how to connect an usb drive

[Gorka Guardiola]

make sure you see it:
usb/probe

ls /dev/sdU*
if it is not there (your usbd does not have disk support built in) run
usb/disk

if it is a fat, you can run

usbfat:

to directly mount it
if not, take a look at it (it is a script)
and usb(4) to understand how things work.

G.

Re: [9fans] radar

[Gorka Guardiola]

 very interesting.  how do i tie this list to some place to grab images?  i'm
 particularly interested in non-us sites.  i want to know of the rains in 
 spain.


It does not fall mainly in the plain...
Sorry, could not resist.

G.

Re: [9fans] usb jtag

[Gorka Guardiola]

On Sun, Oct 2, 2011 at 8:52 PM, erik quanstrom quans...@quanstro.net wrote:
 should the ctl file contain text?  i get something that looks like it should
 be a directory, but it's not.  the manual page doesn't say what should be
 in the jtag file.


Jtagxx is a directory.
jtag is a connection to the jtag.
ctl is ignored for now. It looks like reading
from the ctl returns count rather than 0 which is
why you are seeing noise. I'll send a patch.


G.

Re: [9fans] Announcing Inferno for Android phones

[Gorka Guardiola]

Turn safe search on first.

http://www.amokbuy.com/928-wank-e5-wifi-mobile-phone.html

On Fri, Sep 23, 2011 at 3:55 PM, Brian L. Stuart blstu...@bellsouth.net wrote:
  The Wank E5 was AU$50.

 Why is it that I can't quite summon up the courage to do a
 google search for wank phone?

 Because it will cost you $4.99 a minute?






-- 
- curiosity sKilled the cat

[9fans] iwp9 wip submission deadline

[Gorka Guardiola]

I just wanted to remind everyone that the iwp9's
works in progress submission deadline (1 Oct)
is approaching fast.

Also, if anyone is interested in giving a Plan 9/inferno
related tutorial please contact us at
iwp9trou...@lsub.org.

Re: [9fans] usbuhci bug

[Gorka Guardiola]

On Thu, Sep 1, 2011 at 6:35 PM, erik quanstrom quans...@labs.coraid.com wrote:
  5.  try to slay and restart usb/serial ... no joy there.

 i should have been more clear.  restarting usb/serial worked
 fine.  the interrupt problem didn't go away.


Hmm, but the old usb/serial dies/is killed?. Because it is a very
different problem (in one case it
is most probably a serial problem in the other it is an ehci problem
or hardware).

Another question is, the fail read is because the serial is unplugged
or a hardware
issued error?.

Thanks,

G.

Re: [9fans] jtag programmers

[Gorka Guardiola]

On Tue, Jul 26, 2011 at 9:46 PM, erik quanstrom quans...@quanstro.net wrote:
 can someone point me at a list of plan9 usb/serial compatable
 jtag programmers?


As far as I know, ft2232 chips and their variants may work, but I have only
tried it with the Sheeva plug.

The ft2232 serial chip inside the sheeva
can drive all sorts of serial things, including input to a jtag state machine
if connected properly. Inside the sheeva plug (and some other arm boards),
the chip is actually connected to the jtag input of the SOC inside it,
but you need
the concret details on how this is done for what you are using.

What I do is I program (this is what usb/serial does) the interface connected to
the jtag for the right configuration to drive it. The device is also
programmable
and you need to program it (it is done so that the latency of the USB does not
kill you). Then you need to communicate with the other side, which includes
driving the reset bits (which depend on the concrete electronics connecting the
serial chip to the jtag interface) and then sending the right commands.

I did that for the Arm inside the sheeva, exposing it as a /proc interface and
an acid library on top of it.

Inside my contrib directory there is a file jtag.tgz with all the
stuff I have been
playing with.
All the layers serial chip/mpsse assembler/jtag state machine
driver/arm chain driver/proc filesystem
have been carefully separated, so you can replace any of the
interfaces should you
have a different hardware, though all this is an ongoing job and may change, so
if you do work on it, talk to me off-list.

Enjoy.

G.

Re: [9fans] jtag programmers

[Gorka Guardiola]

On Tue, Jul 26, 2011 at 11:25 PM, Gorka Guardiola pau...@gmail.com wrote:
 On Tue, Jul 26, 2011 at 9:46 PM, erik quanstrom quans...@quanstro.net wrote:
 can someone point me at a list of plan9 usb/serial compatable
 jtag programmers?


 As far as I know, ft2232 chips and their variants may work, but I have only
 tried it with the Sheeva plug.

 The ft2232 serial chip inside the sheeva
 can drive all sorts of serial things, including input to a jtag state machine
 if connected properly. Inside the sheeva plug (and some other arm boards),
 the chip is actually connected to the jtag input of the SOC inside it,
 but you need
 the concret details on how this is done for what you are using.

 What I do is I program (this is what usb/serial does) the interface connected 
 to
 the jtag for the right configuration to drive it. The device is also
 programmable
 and you need to program it (it is done so that the latency of the USB does not
 kill you). Then you need to communicate with the other side, which includes
 driving the reset bits (which depend on the concrete electronics connecting 
 the
 serial chip to the jtag interface) and then sending the right commands.

All this is done outside usb/serial. Only a couple of parameters (latency and
bit mode) are configured in usb/serial and a file is served.

G.

Re: [9fans] GNU/Linux/Plan 9 disto

[Gorka Guardiola]

On Mon, Jul 11, 2011 at 6:41 PM, Jens Staal staal1...@gmail.com wrote:
 Personally, I believe that a Plan9 target for a cross compiler might
 be more interesting. GCC already added support for the Plan9 dialect
 of C. If it also could be made to compile Plan9 binaries, it could be
 used for an alternative self-hosting distro as the one you envisaged.

 I am fully aware that this is quite herretic and probably not very
 interesting for mainline Plan9.


Not a religion, whatever works for you.

Notice though that the kernel and applications need
some more that only the extensions. All of it (including the
assembler) is written supposing caller save
and other inner specifics of kencc that would need to be dealt with
when compiling
for gcc. It would be a port, not only a recompilation.

G.

Re: [9fans] Mousing is faster than typing but users do not believe it

[Gorka Guardiola]

 I have been working in a visually impaired school and I told to the
 list what I saw.
 For me is easier to use the mouse than the keyboard-shortcuts, but for
 blind people mouse is useless and they are heavy users of computers,
 it is not the same as your example.

http://www.hawking.org.uk/index.php/disability/thecomputer

Re: [9fans] Mousing is faster than typing but users do not believe it

[Gorka Guardiola]

On Jun 16, 2011, at 9:30 AM, antonio@gmail.com antonio@gmail.com 
 
 
 For blind people the mouse is useless.
 
 An the computers world have opened a new world of opportunities for
 the blind. Before this era, they had to use heavy machines to write,
 and big, heavy and expensive books to read or study. Today they only
 need a voice synthesizer software, a braille display, and a laptop.
 They used keyboard-shortcuts to move because they don´t have another
 way to speak with computer.

 
To people who cannot move, a
keyboard is useless. What is your point
exactly?. You have a braille line driver
and a braille enabled version of acme with special shortcuts that the mouse 
conspiracy is preventing you from distributing?

G.

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Gorka Guardiola]

On Sun, Jun 12, 2011 at 12:15 AM, Jacob Todd jaketodd...@gmail.com wrote:
 Plan 9 hasn't worked with virtual box for as long as i can remember. Try it
 with qemu if you can.

 On Jun 11, 2011 5:58 PM, Cr0t cr0t...@gmail.com wrote:
 I am unable to load plan9 on the latest version of virtualbox.

 - C


I've been using virtualbox on linux and mac os for a long time.
The only issues I have found have been with the ps/2 mouse emulation
on mac os. You can try the image we have for our students here:
http://lsub.org/plan9alv.tgz

-- 
- curiosity sKilled the cat

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Gorka Guardiola]

On Sun, Jun 12, 2011 at 1:25 AM, Cr0t daywalker cr0t...@gmail.com wrote:
 I saw screenshots that it does work


In case it helps, I use the version you can find here:
http://www.virtualbox.org/wiki/Downloads

and the USB extension pack here:
http://www.virtualbox.org/wiki/Downloads

USB support in MacOs is somewhat flaky, but works most of the time for
mice and usb disks.

G.

Re: [9fans] MetaPost added to kerTeX!

[Gorka Guardiola]

 Numbers are harsh words. Just compare the size of the distribution and
 you will find back the ration given by ron minnich: 1:100.

 I don't think I have done a perfect job, but I claim it is better.

 You can call me Thierry Hercules Laronde! since I have cleaned the
 Augean Stables. Twice (GRASS and TeX distrib).


Awesome job. Thanks!.

Now for the Stymphalian birds!! :-).

- curiosity sKilled the cat