Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Tue, 10 May 2011 01:21: wrote: On 05/10/2011 12:28 AM, Kamo Hiroyasu wrote: I do not understand the benefits of FHS for Unixen other than Linux. Most Unixen, including OpenBSD, are older than FHS and have their own historical constraints. What do we obtain except for switching costs if we accept FHS? It is not we but FHS people that should explain the benefits. If the explanation is available and acceptable, we can accept FHS. Otherwise, we neet not consider FHS. I would see standardization as its own benefit; app developers like having a set of conventions they can rely on. Perhaps, though, I'm not being as clear as I could be. I'm not necessarily advocating that OpenBSD adopt FHS; my goal is that, since we are changing FHS, we not exclude anyone who wants to use it. The standard itself claims to apply to any UNIX-like system, and to not be Linux-specific; I'm wanting to find out if that's true. See: http://www.openbsd.org/cgi-bin/man.cgi?query=hierapropos=0sektion=0ma npath=OpenBSD+Currentarch=i386format=html I think the claim should never have been made. A blatant error like that will hardly enhance the reputation of the standard. The standard only applies to those who choose to use it. I've worked with many Unix/Unix-like OSes and the variations are obviously so many and so different that anyone other than a wet-behind-the-ears noobie or someone stuck with one OS for life would know it. If it's not, all well and good; we proceed on our separate ways. But I don't want to assume that without asking. Lots of luck. The draft LHS was released (IIRC) in 1993 when I was an IBM instructor. It never cut any ice really during my time there which ended in 2005. Six years later and still trying? Give 'em a tick for persistence. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
Date: Mon, 9 May 2011 23:21:23 -0500 From: Marco Peereboom sl...@peereboom.us On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote: (Sorry if this isn't the proper list for this discussion. If not, please point me in the right direction.) The Linux Foundation's LSB workgroup has taken over maintenance of the Filesystem Hierarchy Standard, and is working on a number of updates needed since its last release in 2004. Despite all the Linux in the names above, we're wanting to make sure that the FHS remains independent of any particular UNIX implementation, and continues to be useful to non-Linux UNIXes. Linux is very compatible with Linux and nothing else. Give it up, call it a day. It doesn't even remotely resemble UNIX. You got that wrong Marco. Linux isn't even compatible with Linux these days ;).
support port ranges for sysctl net.inet.(tcp|udp).baddynamic
Hi,
This allows the use of port ranges in sysctl. E.g
net.inet.tcp.baddynamic=+6-61000,-5-51000 # or
net.inet.tcp.baddynamic=1-48000
It also simplifies the parsing a little. Ok?
Index: sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.175
diff -u -p -r1.175 sysctl.c
--- sysctl.c12 Mar 2011 04:54:28 - 1.175
+++ sysctl.c10 May 2011 07:09:45 -
@@ -1003,49 +1003,75 @@ parse(char *string, int flags)
}
}
+static void
+parse_ports(char *portspec, int *port, int *high_port)
+{
+ char *dash;
+ const char *errstr;
+
+ if ((dash = strchr(portspec, '-')) != NULL)
+ *dash++ = '\0';
+ *port = strtonum(portspec, 0, 65535, errstr);
+ if (errstr != NULL)
+ errx(1, port is %s: %s, errstr, portspec);
+ if (dash != NULL) {
+ *high_port = strtonum(dash, 0, 65535, errstr);
+ if (errstr != NULL)
+ errx(1, high port is %s: %s, errstr, dash);
+ if (*high_port *port)
+ errx(1, high port %d is lower than %d,
+ *high_port, *port);
+ } else
+ *high_port = *port;
+}
+
void
parse_baddynamic(int mib[], size_t len, char *string, void **newvalp,
size_t *newsizep, int flags, int nflag)
{
static u_int32_t newbaddynamic[DP_MAPSIZE];
- in_port_t port;
+ int port, high_port, baddynamic_loaded = 0, full_list_set = 0;
size_t size;
char action, *cp;
- const char *errstr;
- if (strchr((char *)*newvalp, '+') || strchr((char *)*newvalp, '-')) {
- size = sizeof(newbaddynamic);
- if (sysctl(mib, len, newbaddynamic, size, 0, 0) == -1) {
- if (flags == 0)
- return;
- if (!nflag)
- (void)printf(%s: , string);
- (void)puts(kernel does contain bad dynamic port
tables);
- return;
- }
-
- while (*newvalp (cp = strsep((char **)newvalp, , \t))
*cp) {
- if (*cp != '+' *cp != '-')
+ while (*newvalp (cp = strsep((char **)newvalp, , \t)) *cp) {
+ if (*cp == '+' || *cp == '-') {
+ if (full_list_set)
errx(1, cannot mix +/- with full list);
action = *cp++;
- port = strtonum(cp, 0, 65535, errstr);
- if (errstr != NULL)
- errx(1, port is %s: %s, errstr, cp);
- if (action == '+')
+ if (!baddynamic_loaded) {
+ size = sizeof(newbaddynamic);
+ if (sysctl(mib, len, newbaddynamic,
+ size, 0, 0) == -1) {
+ if (flags == 0)
+ return;
+ if (!nflag)
+ printf(%s: , string);
+ puts(kernel does contain bad dynamic
+ port tables);
+ return;
+ }
+ baddynamic_loaded = 1;
+ }
+ parse_ports(cp, port, high_port);
+ for (; port = high_port; port++) {
+ if (action == '+')
+ DP_SET(newbaddynamic, port);
+ else
+ DP_CLR(newbaddynamic, port);
+ }
+ } else {
+ if (baddynamic_loaded)
+ errx(1, cannot mix +/- with full list);
+ if (!full_list_set) {
+ bzero(newbaddynamic, sizeof(newbaddynamic));
+ full_list_set = 1;
+ }
+ parse_ports(cp, port, high_port);
+ for (; port = high_port; port++)
DP_SET(newbaddynamic, port);
- else
- DP_CLR(newbaddynamic, port);
- }
- } else {
- (void)memset((void *)newbaddynamic, 0, sizeof(newbaddynamic));
- while (*newvalp (cp = strsep((char **)newvalp, , \t))
*cp) {
- port = strtonum(cp, 0, 65535, errstr);
- if (errstr != NULL)
- errx(1, port is %s: %s, errstr, cp);
- DP_SET(newbaddynamic, port);
}
}
-
*newvalp = (void
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
Many UNIX systems include a hier(7) man page, OpenBSD is no exception. http://www.openbsd.org/cgi-bin/man.cgi?query=hiermanpath=OpenBSD+Currentformat=html -Bryan.
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
* Jeff Licquia j...@licquia.org [2011-05-10 05:36]: My question to you is: do you consider the FHS to be relevant to current and future development of OpenBSD? If not, is this simply due to lack of maintenance; would your interest in the FHS be greater with more consistent updates? we'll happilly adopt FHS if you guys make it match hier(7). -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Tue, May 10, 2011 at 5:33 AM, Jeff Licquia j...@licquia.org wrote: My question to you is: do you consider the FHS to be relevant to current and future development of OpenBSD? If not, is this simply due to lack of maintenance; would your interest in the FHS be greater with more consistent updates? More updates will not atone for /lib64. //art
Re: Synaptics touchpad
On Mon, May 09, 2011 at 11:29:14PM +0200, Matthieu Herrb wrote: On Mon, May 09, 2011 at 04:14:32PM -0400, Brynet wrote: I noticed the following in my Xorg.0.log: Touchpad0: invalid pressure range. defaulting to 0 - 256 Touchpad0: invalid finger width range. defaulting to 0 - 16 Just curious if that's normal. More or less. The test and the error message are lame, to say that the hw specific layer (wsconscomm.c) didn't set the values. Alexandr, I wonder if it's possible to get these filled from the pms driver (it probably means adding more ioctls :() -- Matthieu Herrb The ranges for pressure and width specified in datasheet. I do not see a need for new ioctls. I think is better to explicitly define minp, maxp (etc.) in wsconscomm.c. This will remove confusing messages. -- Alexandr Shadchin Index: wsconscomm.c === RCS file: /cvs/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c,v retrieving revision 1.2 diff -u -p -r1.2 wsconscomm.c --- wsconscomm.c7 May 2011 17:30:31 - 1.2 +++ wsconscomm.c10 May 2011 07:09:20 - @@ -243,6 +243,12 @@ WSConsReadDevDimensions(InputInfoPtr pIn xf86Msg(X_PROBED, %s: y-axis range %d - %d resolution %d\n, pInfo-name, priv-miny, priv-maxy, priv-resy); +priv-minp = 0; +priv-maxp = 256; + +priv-minw = 0; +priv-maxw = 16; + priv-has_pressure = TRUE; priv-has_width = TRUE; priv-has_left = TRUE;
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On 10/05/2011 5:34 PM, Artur Grabowski wrote: On Tue, May 10, 2011 at 5:33 AM, Jeff Licquiaj...@licquia.org wrote: My question to you is: do you consider the FHS to be relevant to current and future development of OpenBSD? If not, is this simply due to lack of maintenance; would your interest in the FHS be greater with more consistent updates? More updates will not atone for /lib64. //art At least /lib64 is better than winblows 64 bit systems system32 - 64 bit dll + apps sysWOW - 32 bit dll + apps How's that for backwards compatibility. Ian McWilliam
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Tue, 10 May 2011 09:05:13 +0200 Landry Breuil wrote: Some parts of FHS won't apply on OpenBSD, like /srv, /opt, Linux ignores security mechanisms like noexec on /tmp, /home and then pointlessly adds /opt seemingly just to annoy people who care about partitioning!! And DON'T try spinning me the line that noexec is pointless on /tmp. I'm glad of your Open thought process though. :-)
Re: ksh completion
On Tue, May 10, 2011 at 08:41:48 +0200, LEVAI Daniel wrote: On Mon, May 09, 2011 at 23:48:46 +0400, Alexander Polakov wrote: * Alexander Polakov polac...@gmail.com [110502 18:19]: Do you mean something like this or I got it all wrong again and we have to wait another 15 years for someone to dig into this? That diff was wrong, this one is likely less wrong. This is working fine for me. I've just found a usecase where it fails to complete a filename: $ touch 'aaa: bbb ccc' $ touch 'aaa: bbc ddd' $ ls -la aTAB $ ls -la aaa:\ bbTAB aaa: bbb ccc aaa: bbc ddd $ ls -la aaa:\ bbcTAB ^^^ nothing happens Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ksh completion
On Tue, May 10, 2011 at 12:28:06 +0200, LEVAI Daniel wrote: On Tue, May 10, 2011 at 08:41:48 +0200, LEVAI Daniel wrote: On Mon, May 09, 2011 at 23:48:46 +0400, Alexander Polakov wrote: * Alexander Polakov polac...@gmail.com [110502 18:19]: Do you mean something like this or I got it all wrong again and we have to wait another 15 years for someone to dig into this? That diff was wrong, this one is likely less wrong. This is working fine for me. I've just found a usecase where it fails to complete a filename: $ touch 'aaa: bbb ccc' $ touch 'aaa: bbc ddd' $ ls -la aTAB $ ls -la aaa:\ bbTAB aaa: bbb ccc aaa: bbc ddd $ ls -la aaa:\ bbcTAB ^^^ nothing happens Apperantly, adding ':' to ESCAPEDCHARS solves the problem. Do you think there is any sideeffect to this? Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote: (Sorry if this isn't the proper list for this discussion. If not, please point me in the right direction.) This is the proper list. Despite all the Linux in the names above, we're wanting to make sure that the FHS remains independent of any particular UNIX implementation, and continues to be useful to non-Linux UNIXes. Good, at least the Linux kids haven't totally forgotten the other grumpies out there :) My question to you is: do you consider the FHS to be relevant to current and future development of OpenBSD? If not, is this simply due to lack of maintenance; would your interest in the FHS be greater with more consistent updates? If you are interested, consider this an invitation to participate. We've set up a mailing list, Web site, etc., and are reviving the old bug tracker. More details can be found here: http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs There are numerous show stoppers, IMO. First off, the document is very Linux specific. Although I can't back up the claim, I'm pretty sure that other OSes wheren't given much thought in the early days of this document. Here are what I would call, show stoppers. And this applies to OpenBSD, as I view it. - OpenBSD has gone to great lengths to centralize all it's configuration into one place: /etc so anything contrarty to that, is a simple no go. - A number of the directories do not make sense on OpenBSD: /lib For what libraries ? /bin and /sbin contains binaries that are statically linked (for a very good reason) so this is pointless. /opt Add-on application packages go into /usr/local/ on OpenBSD and the rest of the *BSDs Here there is one difference between Open and Free that I've come to dislike, FreeBSD stuffs configuration files into /usr/local/etc /media Mount point for removable media, okey; I thought that was what /mnt was for, and /mnt is still in the HFS ? (OK, I can see the point, just to help Gnome users :) /srv This doesn't even have a good rationale in the HFS, what exectly is this supposed to be, I think every *BSD Admin expects to find data for or from services provided by the system inside /var So the above things do not make sense in the general case, and as for the rest of the document, you can easly state that OpenBSD is atleast partially compliant! Unfortunetly, i don't think the HFS is relevant to current or future developments of OpenBSD; Atleast not in it's current state. But I think the document is intresting, and maybe I'll butt in and offer some of my opinions :) Oh! And I almost forgot, we already have our very own HFS, it's in hier(7) :-) regards, thib.
Re: ksh completion
* LEVAI Daniel l...@ecentrum.hu [110510 14:33]:
On Tue, May 10, 2011 at 12:28:06 +0200, LEVAI Daniel wrote:
On Tue, May 10, 2011 at 08:41:48 +0200, LEVAI Daniel wrote:
On Mon, May 09, 2011 at 23:48:46 +0400, Alexander Polakov wrote:
* Alexander Polakov polac...@gmail.com [110502 18:19]:
Do you mean something like this or I got it all wrong again and we
have to wait another 15 years for someone to dig into this?
That diff was wrong, this one is likely less wrong.
This is working fine for me.
I've just found a usecase where it fails to complete a filename:
$ touch 'aaa: bbb ccc'
$ touch 'aaa: bbc ddd'
$ ls -la aTAB
$ ls -la aaa:\ bbTAB
aaa: bbb ccc aaa: bbc ddd
$ ls -la aaa:\ bbcTAB
^^^ nothing happens
Apperantly, adding ':' to ESCAPEDCHARS solves the problem. Do you think
there is any sideeffect to this?
No, I don't think so. Let's just add it and find out in practice.
Index: bin/ksh/edit.c
===
RCS file: /cvs/src/bin/ksh/edit.c,v
retrieving revision 1.34
diff -u -r1.34 edit.c
--- bin/ksh/edit.c 20 May 2010 01:13:07 - 1.34
+++ bin/ksh/edit.c 10 May 2011 10:48:26 -
@@ -357,20 +357,6 @@
toglob = add_glob(str, slen);
- /* remove all escaping backward slashes */
- escaping = 0;
- for (i = 0, idx = 0; toglob[i]; i++) {
- if (toglob[i] == '\\' !escaping) {
- escaping = 1;
- continue;
- }
-
- toglob[idx] = toglob[i];
- idx++;
- if (escaping) escaping = 0;
- }
- toglob[idx] = '\0';
-
/*
* Convert foo* (toglob) to an array of strings (words)
*/
@@ -378,7 +364,7 @@
s = pushs(SWSTR, ATEMP);
s-start = s-str = toglob;
source = s;
- if (yylex(ONEWORD) != LWORD) {
+ if (yylex(ONEWORD|RMBKSLSH) != LWORD) {
source = sold;
internal_errorf(0, fileglob: substitute error);
return 0;
@@ -394,6 +380,20 @@
if (nwords == 1) {
struct stat statb;
+ /* remove all escaping backward slashes (see below) */
+ escaping = 0;
+ for (i = 0, idx = 0; toglob[i]; i++) {
+ if (toglob[i] == '\\' !escaping) {
+ escaping = 1;
+ continue;
+ }
+
+ toglob[idx] = toglob[i];
+ idx++;
+ if (escaping) escaping = 0;
+ }
+ toglob[idx] = '\0';
+
/* Check if globbing failed (returned glob pattern),
* but be careful (E.g. toglob == ab* when the file
* ab* exists is not an error).
@@ -821,7 +821,7 @@
int rval = 0;
for (add = 0, wlen = len; wlen - add 0; add++) {
- if (strchr(\#$'()*;=?[\\]`{|}, s[add]) ||
+ if (strchr(ESCAPEDCHARS, s[add]) ||
strchr(ifs, s[add])) {
if (putbuf_func(s, add) != 0) {
rval = -1;
Index: bin/ksh/lex.c
===
RCS file: /cvs/src/bin/ksh/lex.c,v
retrieving revision 1.45
diff -u -r1.45 lex.c
--- bin/ksh/lex.c 9 Mar 2011 09:30:39 - 1.45
+++ bin/ksh/lex.c 10 May 2011 10:48:26 -
@@ -299,6 +299,10 @@
}
/* FALLTHROUGH */
default:
+ if ((cf RMBKSLSH) strchr(
ESCAPEDCHARS, c)) {
+ *wp++ = QCHAR, *wp++ = c;
+ break;
+ }
Xcheck(ws, wp);
if (c) { /* trailing \ is lost */
*wp++ = CHAR, *wp++ = '\\';
Index: bin/ksh/lex.h
===
RCS file: /cvs/src/bin/ksh/lex.h,v
retrieving revision 1.11
diff -u -r1.11 lex.h
--- bin/ksh/lex.h 29 May 2006 18:22:24 - 1.11
+++ bin/ksh/lex.h 10 May 2011 10:48:26 -
@@ -113,6 +113,7 @@
#define CMDWORD BIT(8) /* parsing simple command (alias related) */
#define HEREDELIM BIT(9) /* parsing ,- delimiter */
#define HEREDOC BIT(10)/* parsing heredoc */
+#define RMBKSLSH BIT(11) /* remove backslashes */
#defineHERES 10 /* max in line */
Index: bin/ksh/sh.h
===
RCS file: /cvs/src/bin/ksh/sh.h,v
retrieving revision 1.30
diff -u -r1.30 sh.h
--- bin/ksh/sh.h4 Jan 2010 18:07:11 -
Re: cron: NULL pointer dereference in load_entry()
On Tue, May 10, 2011 at 06:57:29AM +0200, Otto Moerbeek wrote:
On Mon, May 09, 2011 at 08:51:01PM -0400, Lawrence Teo wrote:
In the load_entry() function in cron's entry.c, calloc() is called
but its return value is never checked to see if it is NULL,
potentially causing a NULL pointer dereference. Since crontab(1)
shares code with cron, it is affected as well.
The following diff adds the check for NULL, and also moves the
cleanup code that addresses this condition to free_entry() in order
to remove duplicate code.
Any thoughts or comments?
Have to look in detail for the stuctural changes, but free(NULL) has
ben OK for ages.
-Otto
Ditto. I think the calloc() return value check is good as e is referenced
in following code. But free_entry should be ok if you ensure you don't
pass it NULL.
Ken
Thanks,
Lawrence
Index: entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.32
diff -u -p -r1.32 entry.c
--- entry.c 29 Oct 2009 18:56:47 - 1.32
+++ entry.c 10 May 2011 00:33:11 -
@@ -57,9 +57,12 @@ static int get_list(bitstr_t *, int, int
void
free_entry(entry *e) {
- free(e-cmd);
- free(e-pwd);
- env_free(e-envp);
+ if (e-cmd)
+ free(e-cmd);
+ if (e-pwd)
+ free(e-pwd);
+ if (e-envp)
+ env_free(e-envp);
free(e);
}
@@ -103,6 +106,10 @@ load_entry(FILE *file, void (*error_func
*/
e = (entry *) calloc(sizeof(entry), sizeof(char));
+ if (e == NULL) {
+ ecode = e_memory;
+ goto eof;
+ }
if (ch == '@') {
/* all of these should be flagged and load-limited; i.e.,
@@ -387,13 +394,8 @@ load_entry(FILE *file, void (*error_func
return (e);
eof:
- if (e-envp)
- env_free(e-envp);
- if (e-pwd)
- free(e-pwd);
- if (e-cmd)
- free(e-cmd);
- free(e);
+ if (e)
+ free_entry(e);
while (ch != '\n' !feof(file))
ch = get_char(file);
if (ecode != e_none error_func)
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
Hi Jeff, Jeff Licquia wrote on Mon, May 09, 2011 at 11:33:27PM -0400: (Sorry if this isn't the proper list for this discussion. If not, please point me in the right direction.) Since your enquiry is not backed up by a patch proposing specific changes to the OpenBSD operating system, this will hardly be considered a technical discussion round here, so m...@openbsd.org might have been more apropriate. On the other hand, i see that thib@ considers tech@ fine, so it may be an edge case. Most importantly, do *not* cross-post. The Linux Foundation's LSB workgroup has taken over maintenance of the Filesystem Hierarchy Standard, and is working on a number of updates needed since its last release in 2004. Despite all the Linux in the names above, we're wanting to make sure that the FHS remains independent of any particular UNIX implementation, and continues to be useful to non-Linux UNIXes. I have briefly looked through it and found the following things you might wish to consider, if - as a first step - you want to make the FHS more accurately describe reality in more operating systems, in particular including OpenBSD: - Consider changing /boot to optional. Our boot loader does not require any additional files, and i guess many people round here would consider one that does as excessive complexity. - Consider changing /lib to optional. In OpenBSD, we consider it as very important that all binaries outside /usr are statically linked on all architectures, in particular that none of the binaries in /bin and /sbin use the run-time linker. We also consider kernel modules more of a nuisance than an asset. Thus, /lib would be pointless in OpenBSD. - Consider changing /media to optional. We do not use it, and i cannot remeber anyone explaining a need for it round here. - Consider changing /opt, /etc/opt, and /var/opt to optional, and add a note that some UNIX systems are using other locations for the same purpose. For example, OpenBSD is using /usr/local. - Consider changing /srv to optional. We do not use it, and i cannot remeber anyone explaining a need for it round here. For the web server, we use /var/www, for example. - Consider moving chown, mount, and umount to /sbin. They are not user commands, but root-only commands for system administration. - Consider moving dmesg and mknod to /sbin. Even though they are not root-only, they are mostly relevant for system administration and hardly ever for users. - Consider deleting false, more, sed, true, and uname from the list of required commands in /bin. They are not fundamental commands and can happily reside in /usr/bin. - Please delete su from the list of required commands in /bin. Using it would be utterly pointless in single-user mode. - Consider deleting the requirement that gzip, gunzip, zcat, and netstat be in /bin. They can happily live in /usr/bin. - Consider deleting the requirement that ping be in /bin. It can be considered a system administration tool and reside in /sbin. - Consider removing the restiction to use /mnt by the installer. The OpenBSD installer does use it, and i don't see any problem with that, nor any need for standardization: What is a portable installer?! - Consider allowing /fastboot as an alternative to /sbin/fastboot. Actually, the former is a more logical placement, as it is related to boot, not to system administration binaries. - Please remove getty from the list of programs required in /sbin. It is not a utility at all, not used for system administration, and pointless in single-user mode. In OpenBSD, it resides in /usr/libexec. - Consider removing the requirements for /usr/bin/X11, /usr/lib/X11, and /usr/include/X11. If any system needs them, fine, let it use them, but i really don't see the point in requiring them everywhere. - Consider deleting python, tclsh, wish, and expect from the list of commands required to be in /usr/bin. According to the rest of the FHS, they should be in /opt, and agreeing with that, we place them in /usr/local. - Consider deleting the requirement for /usr/lib/sendmail, it really seems obsolete by now. - Consider marking /usr/local/etc, /usr/local/games, and /usr/local/src as optional. Some systems may use them, but i don't see a point in requiring them. - Consider allowing /usr/local/libdata, /usr/local/libexec, and /usr/local/info as optional directories. - Consider removing the requirement for /usr/local/share/man. /usr/local/man is required anyway, and that seems sufficient. - The requirements regarding the internal organization of /usr/share/man should be relaxed. Look here: $ man -w cat troff /usr/share/man/cat1/cat.0 /usr/local/man/man1/troff.1 In particular, locale subdirs should not be required. Usually, translations are of inferior quality anyway, so i think the requirement to cope with translated
Ultimas Vacantes: Estrategias de Fidelizacion de Clientes
mail enviado a tech@openbsd.org SEMINARIO TALLER [IMAGE] âEl propssito de todo negocio es Crear y Mantener Clientesâ Theodore Levitt, Economista y Profesor de Harvard Business School Objetivos b: Compartir con los participantes un Marco Metodolsgico que podra ser utilizado al interior de cada una de sus organizaciones para definir un Plan o Estrategia de Fidelizacisn de Clientes, qui servira de medio para incrementar la rentabilidad de la empresa. b: Analizar el efecto boca a boca b: Repasar algunas ticnicas basicas para mejorar el trato, por medio de las reglas de oro para manejo de quejas o reclamos b: Transformar la queja en una oportunidad de negocio Dirigido a: b: Personas relacionadas al ambito comercial, marketing y servicio de atencion al cliente Valor programa completo: $ 275 (precios + IVA) incluye: * cofee breaks certificados material teorico post cursada VISITA NUESTROS PROXIMOS CURSOS [IMAGE] * FORMAS DE PAGO [IMAGE] Lugar [IMAGE] Av. Corrientes 818 - C.A.B.A. Fecha: 13 de Mayo Horario: 9 a 18 Hs TEMARIO DETALLADO PRE RESERVA Expositor Lic. Guillermo Soules [IMAGE] Cronograma - 8:30 hs. Recepcion - 9:00 hs. Inicio 1er.modulo - 11:00 hs. Coffe break - - 11:15 hs. Inicio 2do. modulo - 13:00 hs. Receso - 14:00 hs. Inicio 3er. modulo - 16:30 hs. Cofee break - 16:45 hs. Inicio 4to. modulo - 18:00 hs. Final y entrega de certificados GM - Escuela de Negocios - Corrientes 818 piso 5 - Ciudad Autonoma de Bs. As. Tel: (011) 4718-0458 Si no desea recibir informacisn de nuestras actividades, haga click Desuscrmbeme de esta lista de contactos Muchas Gracias. Este mensaje no puede ser considerado SPAM al contener un mitodo para ser removido de la lista de destinatarios, de acuerdo a la Ley N: 25.326 Art. 27 Inc. 3 (Ley de Habeas Data) de la Republica Argentina. [IMAGE]
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
system32 - 64 bit dll + apps sysWOW - 32 bit dll + apps How's that for backwards compatibility. That's utterly ridiculous. The guy responsible for such things should be fired :)
dhclient(8) vs Nortel NetID vs DHO_DHCP_MESSAGE_TYPE
PR#6543 reports a failure to obtain a DHCP lease. Further investigation
with the submitter has shown that the DHCP server in question (Nortel
NetID v4.5.0) is sensitive to the position of the DHO_DHCP_MESSAGE_TYPE
option.
We currently simply write out the options in numerical order, which
results in several DHCP-only (i.e. not bootp) options being written
before the DHO_DHCP_MESSAGE_TYPE option identifies the packet as
being a DHCP packet rather than a bootp packet.
The diff below ensures that the DHO_DHCP_MESSAGE_TYPE option, if
present, will be written as the very first option. This appears
to fix the problem reported in the PR, although further testing
is still pending.
The diff includes a bit of code refactoring to make clear there is
always enough room in the options area for the cookie and the
DHO_DHCP_MESSAGE_TYPE option.
Of course where there is one sensitive server there may be others.
Tests on various DHCP servers would be appreciated.
As would ok's. :-).
Ken
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.140
diff -u -p -r1.140 dhclient.c
--- dhclient.c 17 Apr 2011 20:06:08 - 1.140
+++ dhclient.c 10 May 2011 18:41:22 -
@@ -1195,8 +1195,7 @@ make_discover(struct client_lease *lease
}
/* Set up the option buffer to fit in a minimal UDP packet. */
- i = cons_options(client-packet.options, 576 - DHCP_FIXED_LEN,
- options);
+ i = cons_options(options);
if (i == -1 || client-packet.options[i] != DHO_END)
error(options do not fit in DHCPDISCOVER packet.);
client-packet_length = DHCP_FIXED_NON_UDP+i+1;
@@ -1264,8 +1263,7 @@ make_request(struct client_lease * lease
}
/* Set up the option buffer to fit in a minimal UDP packet. */
- i = cons_options(client-packet.options, 576 - DHCP_FIXED_LEN,
- options);
+ i = cons_options(options);
if (i == -1 || client-packet.options[i] != DHO_END)
error(options do not fit in DHCPREQUEST packet.);
client-packet_length = DHCP_FIXED_NON_UDP+i+1;
@@ -1332,8 +1330,7 @@ make_decline(struct client_lease *lease)
}
/* Set up the option buffer to fit in a minimal UDP packet. */
- i = cons_options(client-packet.options, 576 - DHCP_FIXED_LEN,
- options);
+ i = cons_options(options);
if (i == -1 || client-packet.options[i] != DHO_END)
error(options do not fit in DHCPDECLINE packet.);
client-packet_length = DHCP_FIXED_NON_UDP+i+1;
Index: dhcp.h
===
RCS file: /cvs/src/sbin/dhclient/dhcp.h,v
retrieving revision 1.8
diff -u -p -r1.8 dhcp.h
--- dhcp.h 15 Oct 2010 09:51:15 - 1.8
+++ dhcp.h 10 May 2011 18:41:22 -
@@ -86,7 +86,8 @@ struct dhcp_packet {
/* Magic cookie validating dhcp options field (and bootp vendor
extensions field). */
-#define DHCP_OPTIONS_COOKIE\143\202\123\143
+#define DHCP_OPTIONS_COOKIE\143\202\123\143
+#define DHCP_OPTIONS_MESSAGE_TYPE \065\001\000
/* DHCP Option codes: */
Index: dhcpd.h
===
RCS file: /cvs/src/sbin/dhclient/dhcpd.h,v
retrieving revision 1.72
diff -u -p -r1.72 dhcpd.h
--- dhcpd.h 4 Apr 2011 11:14:52 - 1.72
+++ dhcpd.h 10 May 2011 18:41:22 -
@@ -207,7 +207,7 @@ extern struct client_state *client;
extern struct client_config *config;
/* options.c */
-int cons_options(unsigned char *, const int, struct option_data *);
+int cons_options(struct option_data *);
char *pretty_print_option(unsigned int, unsigned char *, int, int, int);
void do_packet(int, unsigned int, struct iaddr, struct hardware *);
Index: options.c
===
RCS file: /cvs/src/sbin/dhclient/options.c,v
retrieving revision 1.38
diff -u -p -r1.38 options.c
--- options.c 17 Apr 2011 19:57:23 - 1.38
+++ options.c 10 May 2011 18:41:22 -
@@ -131,18 +131,24 @@ parse_option_buffer(struct option_data *
* to see if it's DHO_END to decide if all the options were copied.
*/
int
-cons_options(unsigned char *buf, const int buflen, struct option_data *options)
+cons_options(struct option_data *options)
{
+ unsigned char *buf = client-packet.options;
+ int buflen = 576 - DHCP_FIXED_LEN;
int ix, incr, length, bufix, code, lastopt = -1;
bzero(buf, buflen);
- if (buflen 3)
- memcpy(buf, DHCP_OPTIONS_COOKIE, 4);
- bufix = 4;
+ memcpy(buf, DHCP_OPTIONS_COOKIE, 4);
+ if (options[DHO_DHCP_MESSAGE_TYPE].data) {
+ memcpy(buf[4], DHCP_OPTIONS_MESSAGE_TYPE, 3);
+ buf[6] = options[DHO_DHCP_MESSAGE_TYPE].data[0];
+ bufix = 7;
+ } else
+
aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
I'm sitting at work, listening to music, debugging a web-application
with JavaScript alert()s. Each time an alert window pops up, the
browser plays a sound. For a brief moment, the volume drops twicefold
then goes back to normal. This is annoying and doesn't make sense.
In real life, if you are surrounded by multiple sound sources, their
sound volumes will not be divided by the total amount of sound sources.
Their sounds will add up until they blur and you can't distinguish
anything anymore. Other operating systems, such as Macrohard Doors, do
mixing by modeling this real world behaviour.
In this sense, aucat violates the principle of least surprise.
I'm used to how sound interacts in real world and then aucat steps in
and introduces it's own laws of physics.
To remedy this, aucat has an option -v, which lets you pre-divide the
volume of inputs. This results in loss of dynamic range (quiet sounds
might disappear and the maximum volume that you can set decreases). And
also, if during usage the count of inputs raises above of what I
predicted, the volume starts to jump up and down again.
Experimentally, I've found that if you do a saturating addition between
inputs, it sounds very much how it might have sounded in real world and
how Macrohard Doors, among others, sounds like when playing
multiple sounds.
So, why is what I'm proposing better than what currently exists:
* Resembles how sound behaves in real world more closely;
* Doesn't violate the principle of least surprise;
* No more annoying volume jumps up and down;
* No need to use the -v option anymore / less stuff to remember / it
just works;
* No more choosing between being annoyed by volume jumps or loosing
dynamic range.
(This doesn't affect the -v option, it remains fully functional.)
Tested on i386 and amd64 with 16 bits and 24 bits.
Index: abuf.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/abuf.h,v
retrieving revision 1.23
diff -u -r1.23 abuf.h
--- abuf.h 21 Oct 2010 18:57:42 - 1.23
+++ abuf.h 10 May 2011 22:58:18 -
@@ -46,7 +46,6 @@
union {
struct {
int weight; /* dynamic range */
- int maxweight; /* max dynamic range allowed */
unsigned vol; /* volume within the dynamic range */
unsigned done; /* frames ready */
unsigned xrun; /* underrun policy */
Index: aparams.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
retrieving revision 1.11
diff -u -r1.11 aparams.h
--- aparams.h 5 Nov 2010 16:42:17 - 1.11
+++ aparams.h 10 May 2011 22:58:18 -
@@ -19,6 +19,8 @@
#include sys/param.h
+#include limits.h
+
#define NCHAN_MAX 16 /* max channel in a stream */
#define RATE_MIN 4000/* min sample rate */
#define RATE_MAX 192000 /* max sample rate */
@@ -64,6 +66,9 @@
typedef short adata_t;
+#define ADATA_MIN SHRT_MIN
+#define ADATA_MAX SHRT_MAX
+
#define ADATA_MUL(x,y) (((int)(x) * (int)(y)) (ADATA_BITS - 1))
#define ADATA_MULDIV(x,y,z)((int)(x) * (int)(y) / (int)(z))
@@ -71,6 +76,9 @@
typedef int adata_t;
+#define ADATA_MIN (-0xff / 2)
+#define ADATA_MAX (0xff / 2)
+
#if defined(__i386__) defined(__GNUC__)
static inline int
@@ -119,6 +127,28 @@
#else
#error only 16-bit and 24-bit precisions are supported
#endif
+
+/* saturating addition */
+static inline adata_t
+adata_sadd(register adata_t x, register adata_t y)
+{
+#if ADATA_BITS = 16
+ register int sum;
+#else
+ register long long sum;
+#endif
+
+ sum = x;
+ sum += y;
+
+ if (sum ADATA_MIN)
+ sum = ADATA_MIN;
+ else if (sum ADATA_MAX)
+ sum = ADATA_MAX;
+
+ return (adata_t) sum;
+}
+#define ADATA_SADD(x,y)adata_sadd(x,y)
#define MIDI_MAXCTL127
#define MIDI_TO_ADATA(m) (aparams_ctltovol[m] (ADATA_BITS - 16))
Index: aproc.c
===
RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 10 May 2011 22:58:19 -
@@ -617,6 +617,7 @@
unsigned i, j, cc, istart, inext, onext, ostart;
unsigned scount, icount, ocount;
int vol;
+ adata_t sample;
#ifdef DEBUG
if (debug_level = 4) {
@@ -673,7 +674,8 @@
idata += istart;
for (i = scount; i 0; i--) {
for (j = cc; j 0; j--) {
- *odata += ADATA_MUL(*idata, vol);
+ sample = ADATA_MUL(*idata, vol);
+ *odata = ADATA_SADD(*odata, sample);
idata++;
Re: vmmap replacement, please test
On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
The newest version of vmmap (as of now) is vmmap_sys.diff.26
Since the diff is scheduled to go in may 20 and has a lot of changes and
fixes, please test this diff and report any failures and successes.
I use this separate e-mail to publish the userspace part of the diff.
--
Ariane
Index: lib/libkvm/kvm_proc.c
===
RCS file: /cvs/src/lib/libkvm/kvm_proc.c,v
retrieving revision 1.42
diff -u -d -p -r1.42 kvm_proc.c
--- lib/libkvm/kvm_proc.c 12 Mar 2011 04:54:28 - 1.42
+++ lib/libkvm/kvm_proc.c 10 May 2011 22:23:15 -
@@ -131,7 +131,7 @@ static void ps_str_e(struct ps_strings *
static char *
_kvm_ureadm(kvm_t *kd, const struct miniproc *p, u_long va, u_long *cnt)
{
- u_long addr, head, offset, slot;
+ u_long addr, offset, slot;
struct vm_anon *anonp, anon;
struct vm_map_entry vme;
struct vm_amap amap;
@@ -140,27 +140,28 @@ _kvm_ureadm(kvm_t *kd, const struct mini
if (kd-swapspc == 0) {
kd-swapspc = _kvm_malloc(kd, kd-nbpg);
if (kd-swapspc == 0)
- return (0);
+ return (NULL);
}
/*
* Look through the address map for the memory object
* that corresponds to the given virtual address.
-* The header just has the entire valid range.
*/
- head = (u_long)p-p_vmspace-vm_map.header;
- addr = head;
+ addr = (u_long)RB_ROOT(p-p_vmspace-vm_map.addr);
while (1) {
+ if (addr == 0)
+ return (NULL);
if (KREAD(kd, addr, vme))
- return (0);
+ return (NULL);
- if (va = vme.start va vme.end
- vme.aref.ar_amap != NULL)
+ if (va vme.start)
+ addr = (u_long)RB_LEFT(vme, addr_entry);
+ else if (va = vme.end + vme.fspace)
+ addr = (u_long)RB_RIGHT(vme, addr_entry);
+ else if (va = vme.end)
+ return (NULL);
+ else
break;
-
- addr = (u_long)vme.next;
- if (addr == head)
- return (0);
}
/*
Index: usr.sbin/procmap/procmap.c
===
RCS file: /cvs/src/usr.sbin/procmap/procmap.c,v
retrieving revision 1.38
diff -u -d -p -r1.38 procmap.c
--- usr.sbin/procmap/procmap.c 23 Apr 2011 01:01:34 - 1.38
+++ usr.sbin/procmap/procmap.c 10 May 2011 22:23:23 -
@@ -169,10 +169,13 @@ struct nlist nl[] = {
void load_symbols(kvm_t *);
void process_map(kvm_t *, pid_t, struct kinfo_proc *, struct sum *);
-size_t dump_vm_map_entry(kvm_t *, struct kbit *, struct kbit *, int,
+struct vm_map_entry *load_vm_map_entries(kvm_t *, struct vm_map_entry *,
+struct vm_map_entry *);
+void unload_vm_map_entries(struct vm_map_entry *);
+size_t dump_vm_map_entry(kvm_t *, struct kbit *, struct vm_map_entry *,
struct sum *);
-char *findname(kvm_t *, struct kbit *, struct kbit *, struct kbit *,
- struct kbit *, struct kbit *);
+char *findname(kvm_t *, struct kbit *, struct vm_map_entry *, struct kbit *,
+struct kbit *, struct kbit *);
int search_cache(kvm_t *, struct kbit *, char **, char *, size_t);
#if 0
void load_name_cache(kvm_t *);
@@ -182,6 +185,19 @@ static void __dead usage(void);
static pid_t strtopid(const char *);
void print_sum(struct sum *, struct sum *);
+/*
+ * uvm_map address tree implementation.
+ */
+static int no_impl(void *, void *);
+static int
+no_impl(void *p, void *q)
+{
+ errx(1, uvm_map address comparison not implemented);
+ return 0;
+}
+
+RB_GENERATE(uvm_map_addr, vm_map_entry, daddrs.addr_entry, no_impl);
+
int
main(int argc, char *argv[])
{
@@ -347,12 +363,12 @@ print_sum(struct sum *sum, struct sum *t
void
process_map(kvm_t *kd, pid_t pid, struct kinfo_proc *proc, struct sum *sum)
{
- struct kbit kbit[4], *vmspace, *vm_map, *header, *vm_map_entry;
- struct vm_map_entry *last;
- u_long addr, next;
+ struct kbit kbit[3], *vmspace, *vm_map;
+ struct vm_map_entry *vm_map_entry;
size_t total = 0;
char *thing;
uid_t uid;
+ int vmmap_flags;
if ((uid = getuid())) {
if (pid == 0) {
@@ -367,13 +383,9 @@ process_map(kvm_t *kd, pid_t pid, struct
vmspace = kbit[0];
vm_map = kbit[1];
- header = kbit[2];
- vm_map_entry = kbit[3];
A(vmspace) = 0;
A(vm_map) = 0;
- A(header) = 0;
- A(vm_map_entry) = 0;
if (pid 0) {
A(vmspace) = (u_long)proc-p_vmspace;
@@ -416,34 +428,41 @@ process_map(kvm_t *kd, pid_t pid, struct
printf(%s %p = {, thing, P(vm_map));
Re: cron: NULL pointer dereference in load_entry()
On Tue, May 10, 2011 at 08:46:04AM -0400, Kenneth R Westerback wrote:
On Tue, May 10, 2011 at 06:57:29AM +0200, Otto Moerbeek wrote:
On Mon, May 09, 2011 at 08:51:01PM -0400, Lawrence Teo wrote:
In the load_entry() function in cron's entry.c, calloc() is called
but its return value is never checked to see if it is NULL,
potentially causing a NULL pointer dereference. Since crontab(1)
shares code with cron, it is affected as well.
The following diff adds the check for NULL, and also moves the
cleanup code that addresses this condition to free_entry() in order
to remove duplicate code.
Any thoughts or comments?
Have to look in detail for the stuctural changes, but free(NULL) has
ben OK for ages.
-Otto
Ditto. I think the calloc() return value check is good as e is referenced
in following code. But free_entry should be ok if you ensure you don't
pass it NULL.
Ken
Otto and Ken,
Thank you for your helpful comments. I have revised the diff
according to your feedback.
I did include a check in free_entry() to ensure that e-envp is not
NULL before passing it to env_free(), since env_free(NULL) would
cause a segfault.
In addition, I modified crontab.c to use free_entry(e) instead of
free(e). This keeps the cleanup code for e consistent throughout the
program.
What do you think of the revised diff? Would appreciate your
thoughts.
Thank you,
Lawrence
Index: crontab.c
===
RCS file: /cvs/src/usr.sbin/cron/crontab.c,v
retrieving revision 1.61
diff -u -p -r1.61 crontab.c
--- crontab.c 4 Apr 2011 15:17:52 - 1.61
+++ crontab.c 11 May 2011 01:40:11 -
@@ -547,7 +547,7 @@ replace_cmd(void) {
case FALSE:
e = load_entry(tmp, check_error, pw, envp);
if (e)
- free(e);
+ free_entry(e);
break;
case TRUE:
break;
Index: entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.32
diff -u -p -r1.32 entry.c
--- entry.c 29 Oct 2009 18:56:47 - 1.32
+++ entry.c 11 May 2011 01:40:11 -
@@ -59,7 +59,8 @@ void
free_entry(entry *e) {
free(e-cmd);
free(e-pwd);
- env_free(e-envp);
+ if (e-envp)
+ env_free(e-envp);
free(e);
}
@@ -103,6 +104,10 @@ load_entry(FILE *file, void (*error_func
*/
e = (entry *) calloc(sizeof(entry), sizeof(char));
+ if (e == NULL) {
+ ecode = e_memory;
+ goto eof;
+ }
if (ch == '@') {
/* all of these should be flagged and load-limited; i.e.,
@@ -387,13 +392,8 @@ load_entry(FILE *file, void (*error_func
return (e);
eof:
- if (e-envp)
- env_free(e-envp);
- if (e-pwd)
- free(e-pwd);
- if (e-cmd)
- free(e-cmd);
- free(e);
+ if (e)
+ free_entry(e);
while (ch != '\n' !feof(file))
ch = get_char(file);
if (ecode != e_none error_func)
Re: cron: NULL pointer dereference in load_entry()
On Tue, May 10, 2011 at 10:01:00PM -0400, Lawrence Teo wrote:
On Tue, May 10, 2011 at 08:46:04AM -0400, Kenneth R Westerback wrote:
On Tue, May 10, 2011 at 06:57:29AM +0200, Otto Moerbeek wrote:
On Mon, May 09, 2011 at 08:51:01PM -0400, Lawrence Teo wrote:
In the load_entry() function in cron's entry.c, calloc() is called
but its return value is never checked to see if it is NULL,
potentially causing a NULL pointer dereference. Since crontab(1)
shares code with cron, it is affected as well.
The following diff adds the check for NULL, and also moves the
cleanup code that addresses this condition to free_entry() in order
to remove duplicate code.
Any thoughts or comments?
Have to look in detail for the stuctural changes, but free(NULL) has
ben OK for ages.
-Otto
Ditto. I think the calloc() return value check is good as e is referenced
in following code. But free_entry should be ok if you ensure you don't
pass it NULL.
Ken
Otto and Ken,
Thank you for your helpful comments. I have revised the diff
according to your feedback.
I did include a check in free_entry() to ensure that e-envp is not
NULL before passing it to env_free(), since env_free(NULL) would
cause a segfault.
In addition, I modified crontab.c to use free_entry(e) instead of
free(e). This keeps the cleanup code for e consistent throughout the
program.
What do you think of the revised diff? Would appreciate your
thoughts.
Thank you,
Lawrence
Index: crontab.c
===
RCS file: /cvs/src/usr.sbin/cron/crontab.c,v
retrieving revision 1.61
diff -u -p -r1.61 crontab.c
--- crontab.c 4 Apr 2011 15:17:52 - 1.61
+++ crontab.c 11 May 2011 01:40:11 -
@@ -547,7 +547,7 @@ replace_cmd(void) {
case FALSE:
e = load_entry(tmp, check_error, pw, envp);
if (e)
- free(e);
+ free_entry(e);
break;
case TRUE:
break;
Index: entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.32
diff -u -p -r1.32 entry.c
--- entry.c 29 Oct 2009 18:56:47 - 1.32
+++ entry.c 11 May 2011 01:40:11 -
@@ -59,7 +59,8 @@ void
free_entry(entry *e) {
free(e-cmd);
free(e-pwd);
- env_free(e-envp);
+ if (e-envp)
+ env_free(e-envp);
free(e);
}
@@ -103,6 +104,10 @@ load_entry(FILE *file, void (*error_func
*/
e = (entry *) calloc(sizeof(entry), sizeof(char));
+ if (e == NULL) {
+ ecode = e_memory;
+ goto eof;
+ }
if (ch == '@') {
/* all of these should be flagged and load-limited; i.e.,
@@ -387,13 +392,8 @@ load_entry(FILE *file, void (*error_func
return (e);
eof:
- if (e-envp)
- env_free(e-envp);
- if (e-pwd)
- free(e-pwd);
- if (e-cmd)
- free(e-cmd);
- free(e);
+ if (e)
+ free_entry(e);
while (ch != '\n' !feof(file))
ch = get_char(file);
if (ecode != e_none error_func)
This seems reasonable at first glance.
Ken
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
clipping is better than normalizing? really?
what about the case where aucat is used for offline mixing?
like the mixerctl change, you are taking away things that exist
for good reason, because it makes *your* situation better in *your*
opinion, when you can (mostly) have what you want with the current
code (if you just try a little).
On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
I'm sitting at work, listening to music, debugging a web-application
with JavaScript alert()s. Each time an alert window pops up, the
browser plays a sound. For a brief moment, the volume drops twicefold
then goes back to normal. This is annoying and doesn't make sense.
In real life, if you are surrounded by multiple sound sources, their
sound volumes will not be divided by the total amount of sound sources.
Their sounds will add up until they blur and you can't distinguish
anything anymore. Other operating systems, such as Macrohard Doors, do
mixing by modeling this real world behaviour.
In this sense, aucat violates the principle of least surprise.
I'm used to how sound interacts in real world and then aucat steps in
and introduces it's own laws of physics.
To remedy this, aucat has an option -v, which lets you pre-divide the
volume of inputs. This results in loss of dynamic range (quiet sounds
might disappear and the maximum volume that you can set decreases). And
also, if during usage the count of inputs raises above of what I
predicted, the volume starts to jump up and down again.
Experimentally, I've found that if you do a saturating addition between
inputs, it sounds very much how it might have sounded in real world and
how Macrohard Doors, among others, sounds like when playing
multiple sounds.
So, why is what I'm proposing better than what currently exists:
* Resembles how sound behaves in real world more closely;
* Doesn't violate the principle of least surprise;
* No more annoying volume jumps up and down;
* No need to use the -v option anymore / less stuff to remember / it
just works;
* No more choosing between being annoyed by volume jumps or loosing
dynamic range.
(This doesn't affect the -v option, it remains fully functional.)
Tested on i386 and amd64 with 16 bits and 24 bits.
Index: abuf.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/abuf.h,v
retrieving revision 1.23
diff -u -r1.23 abuf.h
--- abuf.h21 Oct 2010 18:57:42 - 1.23
+++ abuf.h10 May 2011 22:58:18 -
@@ -46,7 +46,6 @@
union {
struct {
int weight; /* dynamic range */
- int maxweight; /* max dynamic range allowed */
unsigned vol; /* volume within the dynamic range */
unsigned done; /* frames ready */
unsigned xrun; /* underrun policy */
Index: aparams.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
retrieving revision 1.11
diff -u -r1.11 aparams.h
--- aparams.h 5 Nov 2010 16:42:17 - 1.11
+++ aparams.h 10 May 2011 22:58:18 -
@@ -19,6 +19,8 @@
#include sys/param.h
+#include limits.h
+
#define NCHAN_MAX16 /* max channel in a stream */
#define RATE_MIN 4000/* min sample rate */
#define RATE_MAX 192000 /* max sample rate */
@@ -64,6 +66,9 @@
typedef short adata_t;
+#define ADATA_MINSHRT_MIN
+#define ADATA_MAXSHRT_MAX
+
#define ADATA_MUL(x,y) (((int)(x) * (int)(y)) (ADATA_BITS -
1))
#define ADATA_MULDIV(x,y,z) ((int)(x) * (int)(y) / (int)(z))
@@ -71,6 +76,9 @@
typedef int adata_t;
+#define ADATA_MIN(-0xff / 2)
+#define ADATA_MAX(0xff / 2)
+
#if defined(__i386__) defined(__GNUC__)
static inline int
@@ -119,6 +127,28 @@
#else
#error only 16-bit and 24-bit precisions are supported
#endif
+
+/* saturating addition */
+static inline adata_t
+adata_sadd(register adata_t x, register adata_t y)
+{
+#if ADATA_BITS = 16
+ register int sum;
+#else
+ register long long sum;
+#endif
+
+ sum = x;
+ sum += y;
+
+ if (sum ADATA_MIN)
+ sum = ADATA_MIN;
+ else if (sum ADATA_MAX)
+ sum = ADATA_MAX;
+
+ return (adata_t) sum;
+}
+#define ADATA_SADD(x,y) adata_sadd(x,y)
#define MIDI_MAXCTL 127
#define MIDI_TO_ADATA(m) (aparams_ctltovol[m] (ADATA_BITS - 16))
Index: aproc.c
===
RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 10 May 2011 22:58:19 -
@@ -617,6 +617,7 @@
unsigned i, j, cc, istart, inext, onext,
