Re: [9fans] Problem with mk
the problem is not solved, merely one of the manifestation is eliminated. actual solution requires stating all the dependencies. if your list of sources and/or targets is dynamic, consider using mk include: | GEN_DEPS where `GEN_DEPS' is your script generating deps in form TARGET: PREREQUISITE On Wed, Dec 18, 2013 at 10:14 PM, Blake McBride bl...@mcbride.name wrote: Thanks. That is what I was wondering. In the interim, and having a better understanding of what is going on, I was able to re-work my mkfile to support parallel builds where possible. I am, however, experiencing a new problem. I will write that up in a separate post. Thank for the info! Blake On Wed, Dec 18, 2013 at 3:04 PM, Jacob Todd jaketodd...@gmail.com wrote: You could put NPROC=1 in the mkfile.
Re: [9fans] gdbfs
¿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
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] mk time-check/slice issue
So, I think you are saying, that for pieces in a mkfile that take less than 1s to build it is possible for them to be build again, unnecessarily, when mk is run again. This is normal and just the way it is. Is that correct? Correct except for just the way it is. There is a principle involved which is so pervasive to Plan 9 that we often forget to make it explicit. To quote Ken Thompson: Throughout, simplicity has been substituted for efficiency. Complex algorithms are used only if their complexity can be localized. He was writing in 1978 about UNIX, but Plan 9 follows firmly in this tradition. (Linux not so much.) Using the existing file time stamps costs some efficiency, when targets are built more often than necessary. The question is, how significant is this cost compared to the complexity of adding higher time resolution? Note that it's not necessary to run mk repeatedly until it converges -- the algorithm is conservative in the sense that it will not build less than required. So, how many seconds is the unnecessary building of targets actually costing?
Re: [9fans] mk time-check/slice issue
On 19 December 2013 06:07, Bakul Shah ba...@bitblocks.com wrote: I suppose making atime, mtime of type struct timespec would break too much including 9p? It's unfortunate that the times in the protocol have low resolution. I think ix does better.
Re: [9fans] 9front pegs CPU on VMware
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] mk time-check/slice issue
On 12/19/2013 11:59 AM, Charles Forsyth wrote: On 19 December 2013 06:07, Bakul Shah ba...@bitblocks.com mailto:ba...@bitblocks.com wrote: I suppose making atime, mtime of type struct timespec would break too much including 9p? It's unfortunate that the times in the protocol have low resolution. I think ix does better. Is it time for for 9p2014?
Re: [9fans] mk time-check/slice issue
On Wed, Dec 18, 2013 at 11:40 PM, erik quanstrom quans...@quanstro.netwrote: to be more explicit. if a is built from b and mtime(a) = mtime(b), then mk could fail to rebuild a when it needs to. for correctness, mk must use = not . I was thinking about the problem and actually, at least in all circumstances I can think of, changing that one operation from = to would fix the problem. If the times are on the same second, I would never have had time to change it. This would fix the problem. Perhaps this functionality can be controlled by an environment variable like NPROC. I think this is important as follows. If you are working on a project, edit some files, and then perform a mk, if files you haven't changed get built, I for one would constantly question myself, about whether or not I changed that file. It would make things confusing. Also, and perhaps more importantly, it may occur that a very long build is dependant on a very short preceding build. So, the unnecessary rebuild of the fast process can unnecessarily trigger the very long process. This really needs addressing for that reason especially IMO. Thanks. Blake
Re: [9fans] mk time-check/slice issue
I was thinking about the problem and actually, at least in all circumstances I can think of, changing that one operation from = to would fix the problem. If the times are on the same second, I would never have had time to change it. This would fix the problem. Perhaps this functionality can be controlled by an environment variable like NPROC. i thought this idea might come up. i think the reason not to do this is a very fundamental principle: correctness. never give up on correctness. - erik
Re: [9fans] mk time-check/slice issue
On 12/19/2013 11:59 AM, Charles Forsyth wrote: On 19 December 2013 06:07, Bakul Shah ba...@bitblocks.com mailto:ba...@bitblocks.com wrote: I suppose making atime, mtime of type struct timespec would break too much including 9p? It's unfortunate that the times in the protocol have low resolution. I think ix does better. Is it time for for 9p2014? there are ways a file server could address this without changing the protocol. for example, if the fs returned directory entries in oldest-first order, files could be ordered without reference to the time. (not that this is a good idea.) - erik
Re: [9fans] mk time-check/slice issue
On Thu Dec 19 05:02:50 EST 2013, 9f...@hamnavoe.com wrote: So, I think you are saying, that for pieces in a mkfile that take less than 1s to build it is possible for them to be build again, unnecessarily, when mk is run again. This is normal and just the way it is. Is that correct? Correct except for just the way it is. There is a principle involved which is so pervasive to Plan 9 that we often forget to make it explicit. To quote Ken Thompson: Throughout, simplicity has been substituted for efficiency. Complex algorithms are used only if their complexity can be localized. He was writing in 1978 about UNIX, but Plan 9 follows firmly in this tradition. (Linux not so much.) Using the existing file time stamps costs some efficiency, when targets are built more often than necessary. The question is, how significant is this cost compared to the complexity of adding higher time resolution? Note that it's not necessary to run mk repeatedly until it converges -- the algorithm is conservative in the sense that it will not build less than required. So, how many seconds is the unnecessary building of targets actually costing? +1. i just love to hear this approach expressed better than i can. sorry for my redundant post. - erik
Re: [9fans] 9front pegs CPU on VMware
for those without much mwait experience, mwait is a kernel-only primitive (as per the instructions) that pauses the processor until a change has been made in some range of memory. the size is determined by probing the h/w, but think cacheline. so the discussion of locking is kernel specific as well. 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. i assume you mean that there is contention on the cacheline holding the runq lock? i don't think there's classical congestion. as i believe cachelines not involved in the mwait would experience no hold up. 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. mwait() does improve things and one would expect the latency to always be better than spining*. but as it turns out the current scheduler is pretty hopeless in its locking anyway. simply grabbing the lock with lock rather than canlock makes more sense to me. also, using ticket locks (see 9atom nix kernel) will provide automatic backoff within the lock. ticket locks are a poor solution as they're not really scalable but they will scale to 24 cpus much better than tas locks. mcs locks or some other queueing-style lock is clearly the long-term solution. but as charles points out one would really perfer to figure out a way to fit them to the lock api. i have some test code, but testing queueing locks in user space is ... interesting. i need a new approach. - erik * have you done tests on this?
Re: [9fans] 9front pegs CPU on VMware
The original discussion started about the runq spin lock, but I think the scope of the problem is more general and the solution can be applied in user and kernel space both. While in user space you would do sleep(0) in the kernel you would sched() or if you are in the scheduler you would loop doing mwait (see my last email). sched can't be called from sched! The MWAIT instruction can be executed at any privilege level. The MONITOR CPUID feature flag (ECX[bit 3] when CPUID is executed with EAX = 1) indicates the availability of the MONITOR and MWAIT instruction in a processor. When set, the unconditional execution of MWAIT is supported at privilege level 0 and conditional execution is supported at privilege levels 1 through 3 (software should test for the appropriate support of these instructions before unconditional use). There are also other extensions, which I have not tried. I think the ideas can be used in the kernel or in user space, though I have only tried it the kernel and the implementation is only in the kernel right now. thanks, i didn't see that. i assume you mean that there is contention on the cacheline holding the runq lock? i don't think there's classical congestion. as i believe cachelines not involved in the mwait would experience no hold up. I mean congestion in the classical network sense. There are switches and links to exchange messages for the coherency protocol and some them get congested. What I was seeing is the counter of messages growing very very fast and the performance degrading which I interpret as something getting congested. I think when the lock possession is pingponged around (not necessarily contented, but many changes in who is holding the lock or maybe contention) many messages are generated and then the problem occurs. I certainly saw the HW counters for messages go up orders of magnitude when I was not using mwait. any memory access makes the MESI protocol do work. i'm still not convinced that pounding one cache line can create enough memory traffic to sink uninvolved processors. (but i'm not not convinced either.) I think the latency of mwait (this is what I remember for the opterons I was measuring, probably different in intel and in other amd models) opterons have traditionally had terrible memory latency. especially when crossing packages. is actually worse (bigger) than with spinning, but if you have enough processors doing the spinning (not necessarily on the same locks, but are you sure that you're getting fair interleaving with the spin locks? if in fact you're interleaving on big scales (say the same processor gets the lock 100 times in a row), that's cheating a bit, isn't it? also, in user space, there is a 2 order of magnitude difference between sleep(0) and a wakeup. and that's one of the main reasons that the semaphore based lock measures quite poorly. since the latency is not in sleep and wakeup, it appears that it's in context switching. Let us know what your conclusions are after you implement and measure them :-). ticket locks (and some other stuff) are the difference between 200k iops and 1m iops. - erik
Re: [9fans] Problem with mk
On Thu, Dec 19, 2013 at 2:16 AM, dexen deVries dexen.devr...@gmail.comwrote:
the problem is not solved, merely one of the manifestation is eliminated.
actual solution requires stating all the dependencies.
if your list of sources and/or targets is dynamic, consider using mkinclude:
| GEN_DEPS
where `GEN_DEPS' is your script generating deps in form TARGET:
PREREQUISITE
The following mkfile does what I need/expect without explicit dependencies.
# Makefile for Plan 9
/$objtype/mkfile
DYNACE_PATH = ../..
BINDIR = $DYNACE_PATH/bin
LIBDIR = $DYNACE_PATH/lib
INCDIR = $DYNACE_PATH/include
TARGET = main
CLASSES = class1.d
CFILES = main.c
OBJS = ${CFILES:%.c=%.$O} ${CLASSES:%.d=%.$O}
CFLAGS = -DPLAN9 -I$INCDIR -p
C_CLASSES = ${CLASSES:%.d=%.c}
%.$O : %.c
$CC $CFLAGS $stem.c
%.c : %.d
$BINDIR/dpp -g -p $stem.d
$TARGET : generics.$O $OBJS
$LD -o $target $OBJS generics.$O $LIBDIR/Dynace.a
generics.h : generics.1 $CLASSES
$BINDIR/dpp -g -t generics.h generics.c generics.$O -h -s $newprereq
generics.c : generics.h
$BINDIR/dpp -g -c
generics.1 newgens: $INCDIR/generics.h
$BINDIR/dpp -g $INCDIR/generics.h -s $CLASSES -h
touch generics.1
$OBJS $C_CLASSES : generics.h
clean realclean:VQ:
rm -f generics.* $TARGET *.$O $C_CLASSES
[9fans] secstore in p9p, how to use well
Hello everyone, already for some time I've been using secstored+factotum+ssh-agent on linux with p9p. The machine, call it 1, runs basically all the time and let's presume I am logged on it all the time, too. The problem/inconvenience I've had is when I connect to this machine via ssh and want to use the system to connect to yet another machine, call it 2. The best would be if all worked transparently and as soon as I manage to log in to machine 1 I could easily proceed an use the running ssh-agent to get me to machine 2. However, I don't know how to set this up. So far I have, among other things, this in my .profile. -- secstore=localhost export secstore NAMESPACE=/tmp/ns.ruda.0 export NAMESPACE if [ ! -d $NAMESPACE ]; then mkdir $NAMESPACE fi auth=localhost export auth secstored factotum eval `9 ssh-agent -e` --- This ends with the following when I connect: -- secstored: tcp!*!5356: Address already in use secstore password: 9pserve: announce unix!/tmp/ns.ruda.0/factotum: Address already in use factotum: post9pservice factotum: 9pserve failed ssh-agent: announce unix!/tmp/ns.ruda.0/ssh-agent.socket: Address already in use -- which is not unexpected, however, whatever I tried didn't get me to the desired effect. Can you suggest what I should do? Thank you! Ruda Sykora
Re: [9fans] mk time-check/slice issue
I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. how long does it take you to run mk, and then realise you didn't Put your last set of changes? i once changed mk on my local machine to act as you suggest, and then took far too long trying to figure out why the program's behavior didn't reflect the code. more time than i saved from waiting on mk? who knows? theoretical incorrectness has a way of becoming practical... tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 10:30 AM, Tristan 9p...@imu.li wrote: I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. how long does it take you to run mk, and then realise you didn't Put your last set of changes? i once changed mk on my local machine to act as you suggest, and then took far too long trying to figure out why the program's behavior didn't reflect the code. more time than i saved from waiting on mk? who knows? If the situation you describe can happen then it definitely shouldn't be changed. Could you please provide me with a scenario (sequence of events) that would be a problem if mk was changed? I can't think of one. Thanks. Blake
Re: [9fans] mk time-check/slice issue
No one is stopping you from changing it in your installation. On Dec 19, 2013 11:38 AM, Blake McBride bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 10:30 AM, Tristan 9p...@imu.li wrote: I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. how long does it take you to run mk, and then realise you didn't Put your last set of changes? i once changed mk on my local machine to act as you suggest, and then took far too long trying to figure out why the program's behavior didn't reflect the code. more time than i saved from waiting on mk? who knows? If the situation you describe can happen then it definitely shouldn't be changed. Could you please provide me with a scenario (sequence of events) that would be a problem if mk was changed? I can't think of one. Thanks. Blake
Re: [9fans] mk time-check/slice issue
Yea, got that. I just thought it made sense for a wider audience. On Thu, Dec 19, 2013 at 10:40 AM, Jacob Todd jaketodd...@gmail.com wrote: No one is stopping you from changing it in your installation. On Dec 19, 2013 11:38 AM, Blake McBride bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 10:30 AM, Tristan 9p...@imu.li wrote: I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. how long does it take you to run mk, and then realise you didn't Put your last set of changes? i once changed mk on my local machine to act as you suggest, and then took far too long trying to figure out why the program's behavior didn't reflect the code. more time than i saved from waiting on mk? who knows? If the situation you describe can happen then it definitely shouldn't be changed. Could you please provide me with a scenario (sequence of events) that would be a problem if mk was changed? I can't think of one. Thanks. Blake
Re: [9fans] mk time-check/slice issue
// If you are working on a project, edit some files, and then // perform a mk, if files you haven't changed get built, I for // one would constantly question myself, about whether or // not I changed that file. It would make things confusing. It's confusing because it doesn't match your expectations, but that's just as much because you're misunderstanding the intent of the tool. mk is not a tool for checking for changes, it is a tool for ensuring things are up to date. It just isn't designed to provide what you're looking for. That isn't to say that what you're looking for is unreasonable, but mk is not the tool to provide it. As an aside, I'd suggest learning to simply not worry about it. Internalize the fact that mk will sometimes rebuild things that don't strictly need it, but will ensure that things are up to date, and you'll have an easier time of it. // I for one favor practical usefulness over theoretical // correctness. You have not demonstrated anything that significantly impacts mk's practical usefullness. The fact that mk will, in some cases, rebuild things which don't need it doesn't significantly impact its utility for its intended purpose. In Plan 9, the heirarchy of values is different from other systems. Correctness (theoretical or otherwise) and elegance come above utility. That's not to say there are no tradeoffs in the system, but if you're going to give up even a little bit of correctness or elegance (environment variables?!?), you'd best be prepared to demonstrate a rather substantial utility gain. Given how much use this community has gotten out of mk over the past ~27 years, I think it's safe to say we're not sold. Anthony
Re: [9fans] mk time-check/slice issue
how long does it take you to run mk, and then realise you didn't Put your last set of changes? i once changed mk on my local machine to act as you suggest, and then took far too long trying to figure out why the program's behavior didn't reflect the code. more time than i saved from waiting on mk? who knows? If the situation you describe can happen then it definitely shouldn't be changed. Could you please provide me with a scenario (sequence of events) that would be a problem if mk was changed? I can't think of one. i thought i just described one in acme: change stuff middle click Put change more stuff middle click mk middle click Put (within the same second of a file's compile) middle click mk (don't notice that the file wasn't recompiled) tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] mk time-check/slice issue
Blake McBride bl...@mcbride.name wrote: |On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom quanstro@\ |quanstro.netwrote: | | I was thinking about the problem and actually, at least in all | circumstances I can think of, changing that one operation from = to | would fix the problem. If the times are on the same second, I would | | i thought this idea might come up. i think the reason not to do this | is a very fundamental principle: correctness. never give up on | correctness. | |I for one favor practical usefulness over theoretical correctness. An I think on FAT filesystems even giving up correctness won't help you with it's two second resolution. --steffen ---BeginMessage--- On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom quans...@quanstro.netwrote: I was thinking about the problem and actually, at least in all circumstances I can think of, changing that one operation from = to would fix the problem. If the times are on the same second, I would never have had time to change it. This would fix the problem. Perhaps this functionality can be controlled by an environment variable like NPROC. i thought this idea might come up. i think the reason not to do this is a very fundamental principle: correctness. never give up on correctness. I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. Blake ---End Message---
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 11:24 AM, Tristan 9p...@imu.li wrote: how long does it take you to run mk, and then realise you didn't Put your last set of changes? i once changed mk on my local machine to act as you suggest, and then took far too long trying to figure out why the program's behavior didn't reflect the code. more time than i saved from waiting on mk? whoknows? If the situation you describe can happen then it definitely shouldn't be changed. Could you please provide me with a scenario (sequence of events) that would be a problem if mk was changed? I can't think of one. i thought i just described one in acme: change stuff middle click Put change more stuff middle click mk I assume at least one second would transpire here. middle click Put (within the same second of a file's compile) middle click mk (don't notice that the file wasn't recompiled) Would work correctly assuming the above. tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 11:07 AM, a...@9srv.net wrote: // If you are working on a project, edit some files, and then // perform a mk, if files you haven't changed get built, I for // one would constantly question myself, about whether or // not I changed that file. It would make things confusing. It's confusing because it doesn't match your expectations, but that's just as much because you're misunderstanding the intent of the tool. mk is not a tool for checking for changes, it is a tool for ensuring things are up to date. It just isn't designed to provide what you're looking for. That isn't to say that what you're looking for is unreasonable, but mk is not the tool to provide it. As an aside, I'd suggest learning to simply not worry about it. Internalize the fact that mk will sometimes rebuild things that don't strictly need it, but will ensure that things are up to date, and you'll have an easier time of it. // I for one favor practical usefulness over theoretical // correctness. You have not demonstrated anything that significantly impacts mk's practical usefullness. The fact that mk will, in some cases, rebuild things which don't need it doesn't significantly impact its utility for its intended purpose. In Plan 9, the heirarchy of values is different from other systems. Correctness (theoretical or otherwise) and elegance come above utility. That's not to say there are no tradeoffs in the system, but if you're going to give up even a little bit of correctness or elegance (environment variables?!?), you'd best be prepared to demonstrate a rather substantial utility gain. Given how much use this community has gotten out of mk over the past ~27 years, I think it's safe to say we're not sold. Anthony What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. Blake
Re: [9fans] mk time-check/slice issue
Quoting Blake McBride bl...@mcbride.name: What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. eagerly awaiting your discoveries regarding wetness of water
Re: [9fans] mk time-check/slice issue
Quoting Blake McBride bl...@mcbride.name: What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. What I am beginning to understand from comments like this is that there is a club entitlement. Everything ever done by the members of club entitlement is correct, period. No matter what preconceptions, bad habits, or horrible misfeatures exist, they are correct and we will find some way of implementing club entitlement. Anyone can join club entitlement if you assume you cannot be wrong. The main purpose of operating systems (with no exceptions) is to port gnu software. Messing with the premise of club entitlement is significantly whined about on tumblr. Just a newbie's (with six hundred years experience) perception. khm
Re: [9fans] mk time-check/slice issue
You should learn the system before wanting to make changes to it. You're wanting to change how zen is practiced without knowing much zen.
Re: [9fans] mk time-check/slice issue
// What I am beginning to understand from comments like // this is that there is a club Plan-9. Everything ever done // by the originators of club Plan-9 is correct, period. No // mater what exceptions, special cases, or good new ideas // occur, they are wrong and we will find some way of // rationalizing club Plan-9. No, that's not what's going on, and I'm sorry if you've felt attacked. The issue is not that different==bad or that what Ken, Rob, co. have done is infallible. It's just that it seems as though you have not taken the time to understand the reasons behind things being the way they are. There is a reason (or set of reasons) we're using Plan 9, as opposed to doing everything on Linux or whatnot. The system is designed with a different set of principles in mind. My ~27 years comment was not intended to start a years- of-experience pissing match (although arguably I should have anticipated it). My point is rather that the tool's been around for quite some time in productive use, and has undergone changes over that time. It would be wiser to take some time to understand why it is the way it is before concluding that it's been broken for all that time. No, we don't assume that it's correct, either, but it does shift the burden of proof a bit. Also, it's Plan 9 or plan9; never Plan-9. Anthony
Re: [9fans] mk time-check/slice issue
What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. first things first. breaking mk is not a good idea. to see that things could break with rather than = one only needs to consider a dependency that might be modified more than once during a build. for example fu.h that is modified for a debug version built along a non-debug version. perhaps there is some truth to this. certainly plan 9 is not perfect. and certainly there are things you will improve. but on the other hand, many of us have quite a bit of experience, too. - erik
Re: [9fans] mk time-check/slice issue
You can change anything you want on your system; but don't try to ram it down others' throats unless you can prove that you're approach is (a) correct (b) meets the collective sense elegance. Reasoned disagreement is not an attack. On Thu, Dec 19, 2013 at 10:40 AM, Blake McBride bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 11:07 AM, a...@9srv.net wrote: // If you are working on a project, edit some files, and then // perform a mk, if files you haven't changed get built, I for // one would constantly question myself, about whether or // not I changed that file. It would make things confusing. It's confusing because it doesn't match your expectations, but that's just as much because you're misunderstanding the intent of the tool. mk is not a tool for checking for changes, it is a tool for ensuring things are up to date. It just isn't designed to provide what you're looking for. That isn't to say that what you're looking for is unreasonable, but mk is not the tool to provide it. As an aside, I'd suggest learning to simply not worry about it. Internalize the fact that mk will sometimes rebuild things that don't strictly need it, but will ensure that things are up to date, and you'll have an easier time of it. // I for one favor practical usefulness over theoretical // correctness. You have not demonstrated anything that significantly impacts mk's practical usefullness. The fact that mk will, in some cases, rebuild things which don't need it doesn't significantly impact its utility for its intended purpose. In Plan 9, the heirarchy of values is different from other systems. Correctness (theoretical or otherwise) and elegance come above utility. That's not to say there are no tradeoffs in the system, but if you're going to give up even a little bit of correctness or elegance (environment variables?!?), you'd best be prepared to demonstrate a rather substantial utility gain. Given how much use this community has gotten out of mk over the past ~27 years, I think it's safe to say we're not sold. Anthony What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. Blake
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:07 PM, Kurt H Maier k...@sciops.net wrote: Quoting Blake McBride bl...@mcbride.name: What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. What I am beginning to understand from comments like this is that there is a club entitlement. Everything ever done by the members of club entitlement is correct, period. No matter what preconceptions, bad habits, or horrible misfeatures exist, they are correct and we will find some way of implementing club entitlement. Anyone can join club entitlement if you assume you cannot be wrong. The main purpose of operating systems (with no exceptions) is to port gnu software. Messing with the premise of club entitlement is significantly whined about on tumblr. Just a newbie's (with six hundred years experience) perception. Given the number of times I have been enlightened by this group and shown to be clearly wrong, I suppose I am not a member of club entitlement. When I make a query, I am looking for examples of why it is done the way it is. I have provided examples of why the way it works is a problem. Members of club Plan-9 insist that that is just the way it works, as opposed to here is a counterexample why the way it works is better. There is a difference between valid arguments and club allegiance. Blake
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:12 PM, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: You can change anything you want on your system; but don't try to ram it down others' throats unless you can prove that you're approach is (a) correct (b) meets the collective sense elegance. Reasoned disagreement is not an attack. Agreed. I enjoy reasoned debate. I don't enjoy being told the reason is because that's the way we do it. That is not reasoned debate. It is club support.
Re: [9fans] mk time-check/slice issue
Quoting Blake McBride bl...@mcbride.name: There is a difference between valid arguments and club allegiance. You have not demonstrated a necessity for anyone subscribed to this list to give a particular shit about which of the two are at play here. We don't owe you anything, including a defense of plan 9. Patches welcome. khm
Re: [9fans] mk time-check/slice issue
Just a newbie's (with 35 years experience) perception. It sounds like you're saying that you came on the scene around the time UNIX diverged from sanity and devolved into madness. sl
Re: [9fans] mk time-check/slice issue
Hello, On 19 December 2013 20:22, Blake McBride bl...@mcbride.name wrote: Agreed. I enjoy reasoned debate. I don't enjoy being told the reason is because that's the way we do it. That is not reasoned debate. It is club support. I believe, from reading this mailing list for some time, you must be ready to find many stupid reasonings. But opposite is, fortunately, also true: there are people here who can help. Second, you bumped into something which is not 100% to your liking, but on the other hand is simple and works. The simplicity is, in my opinion, what has always counted for people seriously-involved in plan9 and is one of the main advantages of the plan9 programs. Third, it would be, from my experience, an error to expect that there are no errors/flaws in the plan9 programs. When I started to play with plan9, I thought: it is simple, there are no errors. But in reality, whatever I tried, it did not quite work. So, my advice is to be ready to find such problems nearly all the time. And since many people who created the programs are gone by now, there is often little effort to correct these, even if there are true bugs. That's what I think. Ruda
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:43 PM, Rudolf Sykora rudolf.syk...@gmail.comwrote: Hello, On 19 December 2013 20:22, Blake McBride bl...@mcbride.name wrote: Agreed. I enjoy reasoned debate. I don't enjoy being told the reason is because that's the way we do it. That is not reasoned debate. It is club support. I believe, from reading this mailing list for some time, you must be ready to find many stupid reasonings. But opposite is, fortunately, also true: there are people here who can help. Second, you bumped into something which is not 100% to your liking, but on the other hand is simple and works. The simplicity is, in my opinion, what has always counted for people seriously-involved in plan9 and is one of the main advantages of the plan9 programs. Third, it would be, from my experience, an error to expect that there are no errors/flaws in the plan9 programs. When I started to play with plan9, I thought: it is simple, there are no errors. But in reality, whatever I tried, it did not quite work. So, my advice is to be ready to find such problems nearly all the time. And since many people who created the programs are gone by now, there is often little effort to correct these, even if there are true bugs. That's what I think. Ruda Thanks for your thoughtful input! Unfortunately, I have started and continue to provoke a most unhelpful line of discussion. Know that it was (poorly) done with good intention merely to draw a distinction between technical reasons and that's the way we do it attitudes. Blake
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:09 PM, erik quanstrom quans...@labs.coraid.comwrote: What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. first things first. breaking mk is not a good idea. to see that things could break with rather than = one only needs to consider a dependency that might be modified more than once during a build. for example fu.h that is modified for a debug version built along a non-debug version. perhaps there is some truth to this. certainly plan 9 is not perfect. and certainly there are things you will improve. but on the other hand, many of us have quite a bit of experience, too. Thanks for the input. I see your point but would argue (in the most friendly way) that the case you point out would be extremely rare, while the reverse case is very common. Adding sleep to the rarer case makes more sense to me. Again, I propose an option to mk that, IMO, would have wide value. Yes, I realize I can change my version of mk. In that case, I could do as I please. I was hoping to either learn from the experience (perhaps there is a good reason to have mk make the same stuff repeatedly), or be able to contribute. Thanks. Blake
Re: [9fans] mk time-check/slice issue
// I have provided examples of why the way it works is a problem. // Members of club Plan-9 insist that that is just the way it works, as // opposed to here is a counterexample why the way it works is better. No, we don't. You keep hearing that, but nobody's saying it. mk does what it does because it is a more conservative behavior. Yes, things sometimes get needlessly rebuilt. We recognize that, and agree it's not ideal. We are concerned that your suggested change would introduce more problems than it solves. This has all been stated repeatedly, and has nothing to do with it's just the way it works. The closest we've come to that is asserting that there is *a reason* it is that way, and that you seem not to have taken the time to understand what it is. You've been reluctant to accept that idea. Further, while I don't think it's been stated explicitly, the idea of just change the behavior of the out-of-date check based on an environment variable is counter to the general Plan 9 philosophy. Again, not because that's the way it is, but because it makes the tool less predictable and introduces a whole other class of extrnal dependency. This is something Plan 9 intentionally avoids. Anthony
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 1:27 PM, Kurt H Maier k...@sciops.net wrote: Quoting Blake McBride bl...@mcbride.name: There is a difference between valid arguments and club allegiance. You have not demonstrated a necessity for anyone subscribed to this list to give a particular shit about which of the two are at play here. It would take a long email to properly answer that question involving human motivation. I think I'll spare myself the time writing it, and the group with that information. We don't owe you anything, including a defense of plan 9. Agreed. You also don't owe your grocer, your tailor, or your gas station attendant anything either. There is personal gain we all get by shared contribution. Patches welcome. I would be much more interested in producing and providing patches if I wasn't in such fear of upsetting the Plan-9 philosophy. (That is if improvements were sufficient.) I am very, very happy to understand technical reason why things are the way they are. I am also humble enough to know that there is a hell of a lot I can learn from all of you and Plan-9. Hitting roadblocks with that's the way it works and should work gives me nothing (yes, the nothing you owe me). khm
Re: [9fans] mk time-check/slice issue
off topic - for your own amusement, you can search in the mail list archives (http://9fans.net/archive/) DP9IK and SP9SSS gabi On Thursday, December 19, 2013 8:30 PM, Blake McBride bl...@mcbride.name wrote: On Thu, Dec 19, 2013 at 1:09 PM, erik quanstrom quans...@labs.coraid.com wrote: What I am beginning to understand from comments like this is that there is a club Plan-9. Everything ever done by the originators of club Plan-9 is correct, period. No mater what exceptions, special cases, or good new ideas occur, they are wrong and we will find some way of rationalizing club Plan-9. Anyone can join club Plan-9 if you buy into that assumption. The main purpose of Plan-9 forks (with some exceptions) is to port to new hardware. Messing with the premise of club Plan-9 is significantly frowned upon and attacked. Just a newbie's (with 35 years experience) perception. first things first. breaking mk is not a good idea. to see that things could break with rather than = one only needs to consider a dependency that might be modified more than once during a build. for example fu.h that is modified for a debug version built along a non-debug version. perhaps there is some truth to this. certainly plan 9 is not perfect. and certainly there are things you will improve. but on the other hand, many of us have quite a bit of experience, too. Thanks for the input. I see your point but would argue (in the most friendly way) that the case you point out would be extremely rare, while the reverse case is very common. Adding sleep to the rarer case makes more sense to me. Again, I propose an option to mk that, IMO, would have wide value. Yes, I realize I can change my version of mk. In that case, I could do as I please. I was hoping to either learn from the experience (perhaps there is a good reason to have mk make the same stuff repeatedly), or be able to contribute. Thanks. Blake
Re: [9fans] mk time-check/slice issue
Quoting Blake McBride bl...@mcbride.name: Agreed. You also don't owe your grocer, your tailor, or your gas station attendant anything either. There is personal gain we all get by shared contribution. I've selected grocers, tailors, and gas station attendants based on technical merit. How am I to value your input? I would be much more interested in producing and providing patches if I wasn't in such fear of upsetting the Plan-9 philosophy. (That is if improvements were sufficient.) Your total lack of effort in understanding Plan 9 philosophy deftly removes any interest I may have had in your programming output. Your fear is your own problem. I am very, very happy to understand technical reason why things are the way they are. I am also humble enough to know that there is a hell of a lot I can learn from all of you and Plan-9. Hitting roadblocks with that's the way it works and should work gives me nothing (yes, the nothing you owe me). Your humility expresses itself in strange ways, particularly when you arrive in a cloud of smoke, not having read even the most immediately relevant documentation, to tell us that mk is broken because it does not work like make. You won't do it, but I recommend reading the entire post history of 9fans. You will see yourself in several posts throughout the years, as well as techincal discussions you would find illuminating. A large part of the reticence you're running into here is the fact that all of this has been discussed to death, frequently to very little profit. khm
Re: [9fans] mk time-check/slice issue
I would be much more interested in producing and providing patches if I wasn't in such fear of upsetting the Plan-9 philosophy. (That is if improvements were sufficient.) Your total lack of effort in understanding Plan 9 philosophy deftly removes any interest I may have had in your programming output. Your fear is your own problem. i think this is unfair. argument is a way to understand a problem. - erik
Re: [9fans] mk time-check/slice issue
Quoting erik quanstrom quans...@labs.coraid.com: I would be much more interested in producing and providing patches if I wasn't in such fear of upsetting the Plan-9 philosophy. (That is if improvements were sufficient.) Your total lack of effort in understanding Plan 9 philosophy deftly removes any interest I may have had in your programming output. Your fear is your own problem. i think this is unfair. argument is a way to understand a problem. - erik I disagree, and thereby achieve understanding. khm
Re: [9fans] mk time-check/slice issue
On Thu, Dec 19, 2013 at 2:15 PM, Richard Miller 9f...@hamnavoe.com wrote: I see your point but would argue (in the most friendly way) that the case you point out would be extremely rare, while the reverse case is very common. Correctness (in the context of software engineering) doesn't mean doing the right thing in all but the rarest cases; it means doing the right thing in every case. Multiprocessor race conditions are extremely rare, but that doesn't absolve us from putting locks around critical sections in the kernel to guarantee that rare becomes never. Remember mk is not just used to compile stuff. It's a general tool for describing and maintaining dependencies between files or programs. If there are cases (even extremely rare ones) when mk can finish without establishing all the described dependencies, it's broken. Given the simple low-resolution time stamps currenly supported by the Plan 9 file protocol, ensuring that files are updated correctly may come at a cost of doing some redundant work. Think a bit further outside the box than a single-user computer being used to compile programs. Suppose for example there's a cron script which uses mk to update indices for the lookman(1) command, or to update hash files for ndb(8). What if someone (maybe in another timezone!) happens to be editing a man page or ndb file when the cron job activates. Oops, race condition. Extremely rare like most race conditions, but I for one am happy that mk is robust enough do the right thing when the rare occurrence occurs. I see your point, and agree. I suppose I have been arguing for an _option_ that would assist one person working in one tree at a time - a common but not utterly common situation. Also, see my earlier point about fast, prior dependencies unnecessarily triggering very time consuming dependencies. Having been envolved with projects that take 4 hours to build, this could be very significant. Again, the _option_ would help a great deal. Thanks. Blake
Re: [9fans] mk time-check/slice issue
Having been envolved with projects that take 4 hours to build Don't worry, that will never happen in Plan 9. One of the more delightful consequences of putting simplicity first.
Re: [9fans] Ideas from Plan-9
cool man, nice follow up... it's the bell-labs one is code 87... your one was fine but it crashed... and that was the pic I sent... don't worry too much about it... gonna get some of my old hardware after christmas, that I know is supported... I will let you know what happens then my friend... On Wed, Dec 18, 2013 at 8:51 PM, erik quanstrom quans...@labs.coraid.comwrote: On Wed Dec 18 04:48:29 EST 2013, conor.willi...@gmail.com wrote: i'm getting an error code 87 writing usbdisk to my key: according to the web: The second fix prevents USB Image Tool from restoring invalid images in device mode. A valid device mode image has to be multiple of 512. If that’s not the case, the write operation will fail with error code 87 close to the end of the process. To prevent this, USB Image Tool now checks, if the image file size is a multiple of 512. http://www.alexpage.de/tag/usb-image-tool/ i'm not sure what tool you're using, but the image is a multiple of 512 bytes long. ; /n/atom/ftp/usbinstamd64.bz2 /tmp/usbinstamd64 bunzip2 ; ls -ltr /tmp --rw-rw-r-- M 788 quanstro quanstro 524288000 Dec 18 15:48 /tmp/usbinstamd64 ; echo 524288000 % 512 | hoc 0 perhaps something got corrupted. the crash dump is good information but in this case the pc does not appear to be valid, so i don't see what's wrong yet. - erik
Re: [9fans] Ideas from Plan-9
On Thu Dec 19 17:36:48 EST 2013, conor.willi...@gmail.com wrote: cool man, nice follow up... it's the bell-labs one is code 87... your one was fine but it crashed... and that was the pic I sent... don't worry too much about it... gonna get some of my old hardware after christmas, that I know is supported... I will let you know what happens then my friend... if you could grab the original faulting pc, even by taking a movie of the booting screen, that would be pretty helpful. i'm sure i have some bugs. ;-) - erik
Re: [9fans] Ideas from Plan-9
sorry, that went horribly wrong, give me a minute... On Fri, Dec 20, 2013 at 12:29 AM, Conor Williams conor.willi...@gmail.comwrote: wmv ok?... they are also on my google+ On Thu, Dec 19, 2013 at 11:15 PM, Conor Williams conor.willi...@gmail.com wrote: and would you believe, i have the very movie... but... it 43MB... gonna convert it now.. wts! On Thu, Dec 19, 2013 at 10:53 PM, erik quanstrom quans...@labs.coraid.com wrote: On Thu Dec 19 17:36:48 EST 2013, conor.willi...@gmail.com wrote: cool man, nice follow up... it's the bell-labs one is code 87... your one was fine but it crashed... and that was the pic I sent... don't worry too much about it... gonna get some of my old hardware after christmas, that I know is supported... I will let you know what happens then my friend... if you could grab the original faulting pc, even by taking a movie of the booting screen, that would be pretty helpful. i'm sure i have some bugs. ;-) - erik
Re: [9fans] Ideas from Plan-9
here you go... effectless... apologies from Windows Movie Maker ... also on google+ problem diagnosed. mwait required. perhaps i got a bit exuberant requiring mwait support. i'll take a look at this but this evening i'm taking a look at a few bits with the 40gbe driver. - erik
Re: [9fans] Ideas from Plan-9
ack, thanks... On Fri, Dec 20, 2013 at 1:44 AM, erik quanstrom quans...@quanstro.netwrote: here you go... effectless... apologies from Windows Movie Maker ... also on google+ problem diagnosed. mwait required. perhaps i got a bit exuberant requiring mwait support. i'll take a look at this but this evening i'm taking a look at a few bits with the 40gbe driver. - erik
