macppc: print uninorth/u3 revision number
Simple diff to print UniNorth's revision so it becomes easy to know
which AGP chipset people have without looking at the 'eeprom -p' output.
before:
memc0 at mainbus0: uni-n
after:
memc0 at mainbus0: uni-n rev 0xd2
Ok?
Index: dev/uni_n.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/uni_n.c,v
retrieving revision 1.15
diff -u -p -r1.15 uni_n.c
--- dev/uni_n.c 19 Jun 2006 22:41:35 - 1.15
+++ dev/uni_n.c 15 Nov 2012 11:04:42 -
@@ -73,18 +73,23 @@ memcmatch(struct device *parent, void *c
void
memcattach(struct device *parent, struct device *self, void *aux)
{
+ struct memc_softc *sc = (struct memc_softc *)self;
struct confargs *ca = aux;
- int len;
+ u_int32_t rev;
char name[64];
- struct memc_softc *sc = (struct memc_softc *)self;
+ int len;
- len = OF_getprop(ca-ca_node, name, name, sizeof name);
+ len = OF_getprop(ca-ca_node, name, name, sizeof(name));
if (len 0)
name[len] = 0;
+ len = OF_getprop(ca-ca_node, device-rev, rev, sizeof(rev));
+ if (len 0)
+ rev = 0;
+
uni_n_config(name, ca-ca_node);
- printf (: %s\n, name);
+ printf (: %s rev 0x%x\n, name, rev);
memc_attach_children(sc, ca-ca_node);
}
Re: macppc: print uninorth/u3 revision number
On Thu, Nov 15, 2012 at 12:18 PM, Martin Pieuchot mpieuc...@nolizard.org wrote: Simple diff to print UniNorth's revision so it becomes easy to know which AGP chipset people have without looking at the 'eeprom -p' output. before: memc0 at mainbus0: uni-n after: memc0 at mainbus0: uni-n rev 0xd2 Ok? looks good to me. ok
Re: macppc: print uninorth/u3 revision number
Date: Thu, 15 Nov 2012 12:18:06 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
Simple diff to print UniNorth's revision so it becomes easy to know
which AGP chipset people have without looking at the 'eeprom -p' output.
before:
memc0 at mainbus0: uni-n
after:
memc0 at mainbus0: uni-n rev 0xd2
Ok?
ok kettenis@
Index: dev/uni_n.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/uni_n.c,v
retrieving revision 1.15
diff -u -p -r1.15 uni_n.c
--- dev/uni_n.c 19 Jun 2006 22:41:35 - 1.15
+++ dev/uni_n.c 15 Nov 2012 11:04:42 -
@@ -73,18 +73,23 @@ memcmatch(struct device *parent, void *c
void
memcattach(struct device *parent, struct device *self, void *aux)
{
+ struct memc_softc *sc = (struct memc_softc *)self;
struct confargs *ca = aux;
- int len;
+ u_int32_t rev;
char name[64];
- struct memc_softc *sc = (struct memc_softc *)self;
+ int len;
- len = OF_getprop(ca-ca_node, name, name, sizeof name);
+ len = OF_getprop(ca-ca_node, name, name, sizeof(name));
if (len 0)
name[len] = 0;
+ len = OF_getprop(ca-ca_node, device-rev, rev, sizeof(rev));
+ if (len 0)
+ rev = 0;
+
uni_n_config(name, ca-ca_node);
- printf (: %s\n, name);
+ printf (: %s rev 0x%x\n, name, rev);
memc_attach_children(sc, ca-ca_node);
}
mg: make-directory
Hi,
One of the things lacking in mg was support M-x make-directory, which comes
quite handy. This diff mimics the rather silent behaviour of Emacs: there's
basically no feedback in case creating the directory failed for whatever
reason. Should we be more verbose about it, or just stay in line with Emacs?
diff --git def.h def.h
index 6a752d5..11e3c24 100644
--- def.h
+++ def.h
@@ -335,6 +335,7 @@ void dirinit(void);
int changedir(int, int);
int showcwdir(int, int);
int getcwdir(char *, size_t);
+int makedir(int, int);
/* dired.c */
struct buffer *dired_(char *);
diff --git dir.c dir.c
index 2352773..18eb946 100644
--- dir.c
+++ dir.c
@@ -9,6 +9,8 @@
* Modified for MG 2a by Mic Kaczmarczik 03-Aug-1987
*/
+#include sys/stat.h
+
#include def.h
static char mgcwd[NFILEN];
@@ -75,3 +77,62 @@ getcwdir(char *buf, size_t len)
return (TRUE);
}
+
+/* Create the directory and it's parents. */
+/* ARGSUSED */
+int
+makedir(int f, int n)
+{
+ struct stat sb;
+ int finished, ishere;
+ mode_t dir_mode, mode, oumask;
+ char bufc[NFILEN], *path, *slash;
+
+ (void)strlcpy(bufc, curbp-b_cwd, sizeof(bufc));
+ if ((path = eread(Make directory: , bufc, NFILEN,
+ EFDEF | EFNEW | EFCR | EFFILE)) == NULL)
+ return (ABORT);
+ else if (path[0] == '\0')
+ return (FALSE);
+
+ slash = path;
+ oumask = umask(0);
+ mode = 0777 ~oumask;
+ dir_mode = mode | S_IWUSR | S_IXUSR;
+
+ for (;;) {
+ slash += strspn(slash, /);
+ slash += strcspn(slash, /);
+
+ finished = (*slash == '\0');
+ *slash = '\0';
+
+ ishere = !stat(path, sb);
+ if (!finished ishere S_ISDIR(sb.st_mode)) {
+ *slash = '/';
+ continue;
+ }
+
+ if (mkdir(path, finished ? mode : dir_mode) == 0) {
+ if (mode 0777 chmod(path, mode) 0) {
+ umask(oumask);
+ return (ABORT);
+ }
+ } else {
+ if (!ishere || !S_ISDIR(sb.st_mode)) {
+ eerase();
+ umask(oumask);
+ return (ABORT);
+ }
+ }
+
+ if (finished)
+ break;
+
+ *slash = '/';
+ }
+
+ eerase();
+ umask(oumask);
+ return (TRUE);
+}
diff --git file.c file.c
index 8c1297b..2717931 100644
--- file.c
+++ file.c
@@ -258,13 +258,14 @@ readin(char *fname)
dp = dirname(fname);
if (stat(dp, statbuf) == -1 errno == ENOENT) {
/* no read-only; like emacs */
- ewprintf(Parent directory missing);
+ ewprintf(Use M-x make-directory RET RET to
+ create the directory and it's parents);
} else if (access(dp, W_OK) == -1
errno == EACCES) {
ewprintf(File not found and directory
write-protected);
ro = TRUE;
- }
+ }
}
}
if (ro == TRUE)
diff --git funmap.c funmap.c
index 66dd414..9a1be39 100644
--- funmap.c
+++ funmap.c
@@ -198,6 +198,7 @@ static struct funmap functnames[] = {
{csprevfile, cscope-prev-file,},
{cscreatelist, cscope-create-list-of-files-to-index,},
{revertbuffer, revert-buffer,},
+ {makedir, make-directory,},
{NULL, NULL,}
};
diff --git mg.1 mg.1
index 42411c6..3d46675 100644
--- mg.1
+++ mg.1
@@ -662,6 +662,8 @@ Bind a key mapping in the local (topmost) mode.
Unbind a key mapping in the local (topmost) mode.
.It make-backup-files
Toggle generation of backup files.
+.It make-directory
+Prompt the user for a path or directory name which is then created.
.It mark-whole-buffer
Marks whole buffer as a region by putting dot at the beginning and mark
at the end of buffer.
--
Cheers,
Jasper
Stay Hungry. Stay Foolish
##@!#@# gnu tools
external people regularly ask but why you don't want to use GNU/m4 GNU/make GNU/whatever ? Well, latest one, turns out gnu-m4 has relly sloppy regexp handling. Namely, stuff like regexp(`n', `?') *works* with gm4... I know somewhat incredible... our regexpes obviously will not like ? like that, since it's not a normal character, and gnu regexp handling is such a bluberring piece of code that it works... very reproducible, very so secure. Reminds me of gnu libtool dropping silently stuff it doesn't understand... oh wait, of course, *that* regexp is in the autoconf much leading to gnu libtool. Gee, what a surprise...
Re: ##@!#@# gnu tools
On Thu, Nov 15, 2012 at 5:11 PM, Marc Espie es...@nerim.net wrote: external people regularly ask but why you don't want to use GNU/m4 GNU/make GNU/whatever ? External people seem to ask weird questions. I just had to dig into autoconf/auto* because it seems to be a must have for a portable project. Yuck! It is a reason why I don't understand and at the same time deeply respect our ports people: they have to mess with this stuff all the time! For all the GNU people, here is how a Makefile for hello.c should look like: PROG= hello NOMAN= yes .include bsd.prog.mk Yes, you're supposed to provide a man page hello.1 and remove the NOMAN line :) Reyk Well, latest one, turns out gnu-m4 has relly sloppy regexp handling. Namely, stuff like regexp(`n', `?') *works* with gm4... I know somewhat incredible... our regexpes obviously will not like ? like that, since it's not a normal character, and gnu regexp handling is such a bluberring piece of code that it works... very reproducible, very so secure. Reminds me of gnu libtool dropping silently stuff it doesn't understand... oh wait, of course, *that* regexp is in the autoconf much leading to gnu libtool. Gee, what a surprise...
Re: ##@!#@# gnu tools
On Thu, Nov 15, 2012 at 5:53 PM, Reyk Floeter r...@openbsd.org wrote: On Thu, Nov 15, 2012 at 5:11 PM, Marc Espie es...@nerim.net wrote: external people regularly ask but why you don't want to use GNU/m4 GNU/make GNU/whatever ? External people seem to ask weird questions. I just had to dig into autoconf/auto* because it seems to be a must have for a portable project. Yuck! It is a reason why I don't understand and at the same time deeply respect our ports people: they have to mess with this stuff all the time! For all the GNU people, here is how a Makefile for hello.c should look like: PROG= hello NOMAN= yes .include bsd.prog.mk Yes, you're supposed to provide a man page hello.1 and remove the NOMAN line :) not sure gnu people should include bsd.prog.mk (;
Re: ##@!#@# gnu tools
On Nov 15, 2012, at 5:53 PM, Reyk Floeter r...@openbsd.org wrote: On Thu, Nov 15, 2012 at 5:11 PM, Marc Espie es...@nerim.net wrote: external people regularly ask but why you don't want to use GNU/m4 GNU/make GNU/whatever ? External people seem to ask weird questions. I just had to dig into autoconf/auto* because it seems to be a must have for a portable project. Yuck! It is a reason why I don't understand and at the same time deeply respect our ports people: they have to mess with this stuff all the time! The amount of hardcoding in Makefiles for GNU make is astounding given the (flexible enough) design of GNU make. It's not as good as it could be, but there are so many blunt tutorials and documentations available. They all fail to use the tricks that have been used by BSDs for ages. It's always hardcoding this, explicitly calling that... It's not surprising that so many auto* and other magical make systems have been build on top of that rocky foundation. I've tried to work on a GNU compatible prog.mk and the like, but they are barely in shape: https://github.com/fichtner/peak/blob/master/prog.mk And then you still have to deal with differences in include syntax and bugs like not handling paths in multiple layers of include files correctly. For all the GNU people, here is how a Makefile for hello.c should look like: PROG= hello NOMAN= yes .include bsd.prog.mk Yes, you're supposed to provide a man page hello.1 and remove the NOMAN line :) Reyk Well, latest one, turns out gnu-m4 has relly sloppy regexp handling. Namely, stuff like regexp(`n', `?') *works* with gm4... I know somewhat incredible... our regexpes obviously will not like ? like that, since it's not a normal character, and gnu regexp handling is such a bluberring piece of code that it works... very reproducible, very so secure. Reminds me of gnu libtool dropping silently stuff it doesn't understand... oh wait, of course, *that* regexp is in the autoconf much leading to gnu libtool. Gee, what a surprise...
Re: ##@!#@# gnu tools
On Thu, Nov 15, 2012 at 05:53:52PM +0100, Reyk Floeter wrote:
External people seem to ask weird questions.
I just had to dig into autoconf/auto* because it seems to be a must
have for a portable project.
Here's a simple configure replacement you could use for such projects:
#!/bin/sh
foo() {
ed -s $0 - 'EOF'
/^echo/,/^foo$/d
w
q
EOF
exit
}
echo Just edit the Makefile.
foo
echo Please do not run this script again.
foo
echo I told you, didn't I?
foo
echo STOP IT! Or I'll destroy myself.
foo
rm -f -- $0
Of course, the very first message is only necessary if there actually
*are* some system dependend things that can't be easily set by just
passing some variable assignments to make(1).
Ciao,
Kili
ps: while we are about annoyances -- I thought about a little project
(suitable for ports category education which would
- remove a random file when run without arguments.
- remove a few random files when run with -?.
- remove a lot of random files when run with --help.
This would be clearly documented in the man page of it.
Re: Major dhclient(8) changes - no more dhclient-script
On Wed, Nov 14, 2012 at 08:35:52AM -0500, Kenneth R Westerback wrote: On Tue, Nov 13, 2012 at 03:14:40PM -0500, sven falempin wrote: 2012/11/9 Kenneth R Westerback kwesterb...@rogers.com Those of you following -current or running very recent snaps may have noticed a lot of changes to dhclient in the last couple of weeks. Aside from some major clean up, these changes revolve around the elimination of the dhclient-script as both detrimental to sanity and our ability to move forward to better network configuration automation. So far a couple of uses for dhclient-script have been reported and workarounds have to be developed for these scenarios. But now that most of the changes are committed we are very interested in making sure that scenarios that lead people to modify dhclient-script are identified sooner rather than later. So please test the new dhclient(8) in as many situations as possible and report both 'noraml' bugs/regressions and problems you have not been able to solve without dhclient-script. Thanks. How to prevent deleting of /etc/resolv.conf by dhclient? I have this: # egrep -v ^#|^[ \t]*$ /etc/dhclient.conf ignore domain-name-servers, domain-name; The goal is to have always my own /etc/resolv.conf. I'm using pdnsd, the best would be to catch offerent dns server and if OK I would like to do someting with that. (I was using that on Ubuntu, caching if offered dns servers are ones from my job, if so and then into pdnsd setup; because internal company's dns server sucked a lot and I was using other public dns for normal recursive queries but going via internal company's ones only for specific domains.) Anway, I don't like to be without /etc/resolv.conf and also have there so stupid dns offered by dhcp. Thanks for tips. jirib
Re: Major dhclient(8) changes - no more dhclient-script
On Fri, Nov 09, 2012 at 09:44:01AM -0500, Kenneth R Westerback wrote: Those of you following -current or running very recent snaps may have noticed a lot of changes to dhclient in the last couple of weeks. Aside from some major clean up, these changes revolve around the elimination of the dhclient-script as both detrimental to sanity and our ability to move forward to better network configuration automation. So far a couple of uses for dhclient-script have been reported and workarounds have to be developed for these scenarios. But now that most of the changes are committed we are very interested in making sure that scenarios that lead people to modify dhclient-script are identified sooner rather than later. So please test the new dhclient(8) in as many situations as possible and report both 'noraml' bugs/regressions and problems you have not been able to solve without dhclient-script. Thanks. Ken Well, resolv.conf(5) has many neat options which one could like to have added into resolv.conf even when using dhcp to get dns servers. One of them could be: family, some options like tcp... I don't want to be nitpick but with personalized dhclient-script one could code whatever to have valid resolv.conf(5) settings in his /etc/resolv.conf. jirib
Re: Major dhclient(8) changes - no more dhclient-script
On 2012/11/15 16:59, Jiri B wrote: On Fri, Nov 09, 2012 at 09:44:01AM -0500, Kenneth R Westerback wrote: Those of you following -current or running very recent snaps may have noticed a lot of changes to dhclient in the last couple of weeks. Aside from some major clean up, these changes revolve around the elimination of the dhclient-script as both detrimental to sanity and our ability to move forward to better network configuration automation. So far a couple of uses for dhclient-script have been reported and workarounds have to be developed for these scenarios. But now that most of the changes are committed we are very interested in making sure that scenarios that lead people to modify dhclient-script are identified sooner rather than later. So please test the new dhclient(8) in as many situations as possible and report both 'noraml' bugs/regressions and problems you have not been able to solve without dhclient-script. Thanks. Ken Well, resolv.conf(5) has many neat options which one could like to have added into resolv.conf even when using dhcp to get dns servers. One of them could be: family, some options like tcp... I use resolv.conf.tail for these.. nameserver 127.0.0.1 search spacehopper.org lookup file bind family inet6 inet4 and skip requesting name-servers in dhclient.conf: request subnet-mask, broadcast-address, routers;
