Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
> Date: Mon, 9 May 2011 23:21:23 -0500 > From: Marco Peereboom > > 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 ;).
Re: ksh completion
On Mon, May 09, 2011 at 23:48:46 +0400, Alexander Polakov wrote: > * Alexander Polakov [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. The previous diff indeed had something weird with it, because I had to madly escape '[' characters in the colour codes in my prompt. But knowing that nearly no one uses coloured prompt except me, I kept my mouth shut :) 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 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=hier&apropos=0&sektion=0&ma npath=OpenBSD+Current&arch=i386&format=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 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
On Tue, May 10, 2011 at 01:21:15AM -0400, Jeff Licquia wrote: > 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. Perhaps then you would be interested in item 14 of the OpenBSD porting checklist: http://www.openbsd.org/porting/checklist.html l8rZ, -- andrew - http://afresh1.com I wish life had an UNDO function.
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
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. If it's not, all well and good; we proceed on our separate ways. But I don't want to assume that without asking.
Re: cron: NULL pointer dereference in load_entry()
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
>
> 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
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. Kamo Hiroyasu [Kamo is the family name and Hiroyasu the given name.] From: Jeff Licquia Subject: Filesystem Hierarchy Standard (FHS) and OpenBSD Date: Mon, 09 May 2011 23:33:27 -0400 > (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. > > 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
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.) > > 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. > > 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
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Mon, 9 May 2011, 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. > > My question to you is: do you consider the FHS to be relevant to current and > future development of OpenBSD? No, OpenBSD follows BSD traditions. > If not, is this simply due to lack of > maintenance; would your interest in the FHS be greater with more consistent > updates? No, it isn't a matter of update frequency. Viva la difference! -d
Filesystem Hierarchy Standard (FHS) and OpenBSD
(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. 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
0fertas temporada baja y Vacaciones de Invierno
Ofertastemporada baja y Vacaciones de Invierno Ganá4 noches All Inclusive en El Club Med ItaparicaVER AQUI Ofertasde Brasil en Temporada Baja VER AQUI PromoCuba 9 días 8 noches desde Usd 1075más imp VER AQUI Fórmula1 en Brasil en noviembre VER AQUI TurquíaGrecia y Egipto 10 días 9 noches VERAQUI Cataratasen Bus a un precio increible desde $ 870 VER AQUI Escapadas a Colonia Uruguay VER AQUI Norte de Argentina Salta Y Jujuy VER AQUI Tarifasde Ski en Cerro Castor VER AQUI
cron: NULL pointer dereference in load_entry()
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?
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: Remove the freelist member from vm_physseg
On Mon, May 09, 2011 at 07:22:01PM +0100, Owain Ainsworth wrote:
> The new world order of pmemrange makes this data completely redundant
> (being dealt with by the pmemrange constraints instead). Remove all code
> that messes with the freelist.
>
> While touching every caller of uvm_page_physload() anyway, add the flags
> argument to all callers (all but one is 0 and that one already used
> PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
> without it.
>
> Should shrink the code a bit, as well.
>
> My machine room is still in a mess, so this has only had the build
> testing on i386 and amd64. I'd appreciate if people could check the
> others since it'll be a while before I can get all my machines properly
> set up.
>
> ok?
matthew@ kindly pointed out two cases there I had missed the flags
addition.
diff --git arch/alpha/alpha/machdep.c arch/alpha/alpha/machdep.c
index 2a5a8de..216a681 100644
--- arch/alpha/alpha/machdep.c
+++ arch/alpha/alpha/machdep.c
@@ -559,7 +559,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", pfn0, kernstartpfn);
#endif
uvm_page_physload(pfn0, kernstartpfn,
- pfn0, kernstartpfn, VM_FREELIST_DEFAULT);
+ pfn0, kernstartpfn, 0);
}
#ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
@@ -573,7 +573,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", kernendpfn, pfn1);
#endif
uvm_page_physload(kernendpfn, pfn1,
- kernendpfn, pfn1, VM_FREELIST_DEFAULT);
+ kernendpfn, pfn1, 0);
}
} else {
/*
@@ -583,8 +583,7 @@ nobootinfo:
printf("Loading cluster %d: 0x%lx / 0x%lx\n", i,
pfn0, pfn1);
#endif
- uvm_page_physload(pfn0, pfn1, pfn0, pfn1,
- VM_FREELIST_DEFAULT);
+ uvm_page_physload(pfn0, pfn1, pfn0, pfn1, 0);
}
#ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
diff --git arch/alpha/include/vmparam.h arch/alpha/include/vmparam.h
index 24fb644..5ff1c06 100644
--- arch/alpha/include/vmparam.h
+++ arch/alpha/include/vmparam.h
@@ -125,9 +125,6 @@
#defineVM_PHYSSEG_STRATVM_PSTRAT_BSEARCH
#defineVM_PHYSSEG_NOADD/* no more after
vm_mem_init */
-#defineVM_NFREELIST1
-#defineVM_FREELIST_DEFAULT 0
-
/*
* pmap-specific data stored in the vm_physmem[] array.
*/
diff --git arch/amd64/amd64/machdep.c arch/amd64/amd64/machdep.c
index 9ca1a7a..bc728a3 100644
--- arch/amd64/amd64/machdep.c
+++ arch/amd64/amd64/machdep.c
@@ -1360,7 +1360,6 @@ init_x86_64(paddr_t first_avail)
for (x = 0; x < mem_cluster_cnt; x++) {
paddr_t seg_start = mem_clusters[x].start;
paddr_t seg_end = seg_start + mem_clusters[x].size;
- int seg_type;
if (seg_start < first_avail) seg_start = first_avail;
if (seg_start > seg_end) continue;
@@ -1368,20 +1367,12 @@ init_x86_64(paddr_t first_avail)
physmem += atop(mem_clusters[x].size);
- /* XXX - Should deal with 4GB boundary */
- if (seg_start >= (1UL<<32))
- seg_type = VM_FREELIST_HIGH;
- else if (seg_end <= 16*1024*1024)
- seg_type = VM_FREELIST_LOW;
- else
- seg_type = VM_FREELIST_DEFAULT;
-
#if DEBUG_MEMLOAD
printf("loading 0x%lx-0x%lx (0x%lx-0x%lx)\n",
seg_start, seg_end, atop(seg_start), atop(seg_end));
#endif
uvm_page_physload(atop(seg_start), atop(seg_end),
- atop(seg_start), atop(seg_end), seg_type);
+ atop(seg_start), atop(seg_end), 0);
}
#if DEBUG_MEMLOAD
printf("avail_start = 0x%lx\n", avail_start);
diff --git arch/amd64/include/vmparam.h arch/amd64/include/vmparam.h
index 494416f..bc22bac 100644
--- arch/amd64/include/vmparam.h
+++ arch/amd64/include/vmparam.h
@@ -110,11 +110,6 @@
#define VM_PHYSSEG_STRAT VM_PSTRAT_BIGFIRST
#define VM_PHYSSEG_NOADD /* can't add RAM after vm_mem_init */
-#defineVM_NFREELIST3
-#defineVM_FREELIST_DEFAULT 0
-#defineVM_FREELIST_LOW 1
-#defineVM_FREELIST_HIGH2
-
#define __HAVE_VM_PAGE_MD
struct pv_entry;
struct vm_page_md {
diff --git arch/armish/armish/armish_machdep.c
arch/armish/armish/armish_machdep.c
index d8ac7f6..850694f 100644
--- arch/armish/armish/armish_machdep.c
+++ arch/armish/armish/armish_machdep.c
@@ -750,8 +750,7 @@ initarm(void *arg)
#endif
uvm_setpagesize(); /* initialize PAGE_SIZE-dependent variables */
uvm_page_phys
Re: Synaptics touchpad
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
Re: Synaptics touchpad
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. -Bryan.
Re: ksh completion
* Alexander Polakov [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.
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 9 May 2011 19:44:06 -
@@ -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 9 May 2011 19:44:07 -
@@ -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 9 May 2011 19:44:07 -
@@ -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 - 1.30
+++ bin/ksh/sh.h9 May 2011 19:44:07 -
@@ -398,6 +398,9 @@
#define OBRACE '{'
#define CBRACE '}'
+/* Characters to be escaped */
+#define ESCAPEDCHARS "\"#$&'()*;<=>?[\\]`{|}"
+
/* Determine the location of the system (common) profile */
#define KSH_SYSTEM_PROFILE "/etc/profile"
--
Alexander Polakov | plhk.ru
Re: Synaptics touchpad
On Sun, May 08, 2011 at 09:58:44PM -0400, Brynet wrote: > Thanks to both of you, it works fairly well on my Acer Aspire 5551 laptop > with > Synaptics 7.2 firmware. > > What's the prefered method of configuration? xorg.conf/synclient or > xinput? It depends on a lot of things. If you're using Gnome/KDE/XFCE and it has a builting configuration widget for synaptics, use whatever they provide. Otherwise, xorg.conf is good for defaults you want to keep for all users. The synclient program should be mostly useless now that xinput provides a device-independant way to configure input devices. Unfortunatly the 'xinput(1)' command is not really user-friendly, so synclient may still be useful in a .xsession or .xinitrc if someone wants to setup things for one session only. > > I use the following from .xintrc/.xsession: > synclient TapButton1=1 > synclient TapButton2=2 > synclient TapButton3=3 > synclient VertEdgeScroll=1 > synclient VertTwoFingerScroll=0 > syndaemon -d -t -K > > The sensitivity is a bit high for tap-to-click though, especially for buttons > 2 > and 3.. for bringing up cwm menu's, etc. There are several parameters (FingerLow/FingerHigh, MaxTapTIme, MaxDoubleTapTime) that can influnce this. Play with them. > > It's still something that has been missing for a long time, the physical > buttons are annoying to use on my laptop.. fortunately button 1 was > implemented > in the firmware (..and hence worked with xf86-input-mouse). That's not too hard to add to the emulation mode. I just don't want to add too many features to that mode (that would end up implementing the whole xf86-input-synaptics driver in the kernel). -- Matthieu Herrb
Re: %ls and %lc for vfprintf()
On Fri, Apr 29, 2011 at 01:09:56PM +0200, Stefan Sperling wrote:
> Anyone?
Updated diff following the vfwprintf() memory leak fix.
The previous version of this diff had the same bug.
Index: Makefile.inc
===
RCS file: /cvs/src/lib/libc/stdio/Makefile.inc,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile.inc
--- Makefile.inc28 Apr 2011 17:38:46 - 1.16
+++ Makefile.inc29 Apr 2011 12:52:29 -
@@ -3,7 +3,7 @@
# stdio sources
.PATH: ${LIBCSRCDIR}/stdio
-CFLAGS+=-DFLOATING_POINT
+CFLAGS+=-DFLOATING_POINT -DPRINTF_WIDE_CHAR
SRCS+= asprintf.c clrerr.c fclose.c fdopen.c feof.c ferror.c fflush.c fgetc.c \
fgetln.c fgetpos.c fgets.c fileno.c findfp.c flags.c fopen.c \
Index: vfprintf.c
===
RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v
retrieving revision 1.60
diff -u -p -r1.60 vfprintf.c
--- vfprintf.c 22 Dec 2010 14:54:44 - 1.60
+++ vfprintf.c 8 May 2011 23:17:09 -
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include "local.h"
#include "fvwrite.h"
@@ -79,6 +80,8 @@ union arg {
double doublearg;
long double longdoublearg;
#endif
+ wint_t wintarg;
+ wchar_t *pwchararg;
};
static int __find_arguments(const char *fmt0, va_list ap, union arg **argtable,
@@ -138,6 +141,72 @@ __sbprintf(FILE *fp, const char *fmt, va
return (ret);
}
+#ifdef PRINTF_WIDE_CHAR
+/*
+ * Convert a wide character string argument for the %ls format to a multibyte
+ * string representation. If not -1, prec specifies the maximum number of
+ * bytes to output, and also means that we can't assume that the wide char
+ * string is null-terminated.
+ */
+static char *
+__wcsconv(wchar_t *wcsarg, int prec)
+{
+ mbstate_t mbs;
+ char buf[MB_LEN_MAX];
+ wchar_t *p;
+ char *convbuf;
+ size_t clen, nbytes;
+
+ /* Allocate space for the maximum number of bytes we could output. */
+ if (prec < 0) {
+ memset(&mbs, 0, sizeof(mbs));
+ p = wcsarg;
+ nbytes = wcsrtombs(NULL, (const wchar_t **)&p, 0, &mbs);
+ if (nbytes == (size_t)-1) {
+ errno = EILSEQ;
+ return (NULL);
+ }
+ } else {
+ /*
+* Optimisation: if the output precision is small enough,
+* just allocate enough memory for the maximum instead of
+* scanning the string.
+*/
+ if (prec < 128)
+ nbytes = prec;
+ else {
+ nbytes = 0;
+ p = wcsarg;
+ memset(&mbs, 0, sizeof(mbs));
+ for (;;) {
+ clen = wcrtomb(buf, *p++, &mbs);
+ if (clen == 0 || clen == (size_t)-1 ||
+ nbytes + clen > (size_t)prec)
+ break;
+ nbytes += clen;
+ }
+ if (clen == (size_t)-1) {
+ errno = EILSEQ;
+ return (NULL);
+ }
+ }
+ }
+ if ((convbuf = malloc(nbytes + 1)) == NULL)
+ return (NULL);
+
+ /* Fill the output buffer. */
+ p = wcsarg;
+ memset(&mbs, 0, sizeof(mbs));
+ if ((nbytes = wcsrtombs(convbuf, (const wchar_t **)&p,
+ nbytes, &mbs)) == (size_t)-1) {
+ free(convbuf);
+ errno = EILSEQ;
+ return (NULL);
+ }
+ convbuf[nbytes] = '\0';
+ return (convbuf);
+}
+#endif
#ifdef FLOATING_POINT
#include
@@ -260,7 +329,9 @@ __vfprintf(FILE *fp, const char *fmt0, _
size_t argtablesiz;
int nextarg;/* 1-based argument index */
va_list orgap; /* original argument pointer */
-
+#ifdef PRINTF_WIDE_CHAR
+ char *convbuf; /* buffer for wide to multi-byte conversion */
+#endif
/*
* Choose PADSIZE to trade efficiency vs. size. If larger printf
* fields occur frequently, increase PADSIZE and make the initialisers
@@ -402,7 +473,9 @@ __vfprintf(FILE *fp, const char *fmt0, _
uio.uio_resid = 0;
uio.uio_iovcnt = 0;
ret = 0;
-
+#ifdef PRINTF_WIDE_CHAR
+ convbuf = NULL;
+#endif
memset(&ps, 0, sizeof(ps));
/*
* Scan the format for conversions (`%' character).
@@ -553,8 +626,28 @@ reswitch: switch (ch) {
flags |= SIZEINT;
goto rflag;
case 'c':
- *(cp = buf) = GETARG(int);
- size = 1;
+#ifdef PRINTF_WIDE_CHAR
+
Nuevos Productos, Nuevas colecciones!
Estimado Cliente tech@openbsd.org Estas son las nuevas novedades que tenemos para presentarle. Si no puede visualizar el mensaje ingrese al siguiente link: http://www.cuerosliberty.com.ar/newsletter/mayo11.htm Ante cualquier consulta no dude en contactarse. Un cordial saludo. Cueros Liberty Reconquista 573, CABA Tel. (11) 4314-0766 Horario: 10.30 a 19 hs. Paseo Pinamar Plaza, Pinamar Local 9 y Gondola 10 http://www.cuerosliberty.com.ar/";>www.cuerosliberty.com.ar http://www.facebook.com/cuerosliberty";>www.facebook.com/cuerosliberty
Re: /etc/daily ROOTBACKUP duid patch
On Mon, May 09, 2011 at 01:17:03PM +0200, Ingo Schwarze wrote: > Clearly, at least part of daily(8) has to be rewritten in Perl, > and clearly, the ROOTBACKUP handling is part of the part. > > If we decide to just rewrite the ROOTBACKUP handling, i'd suggest > simply moving it from daily(8) to security(8). It is functionally > similar to what security(8) already does (consider changelist(5)). > Besides, one might consider backing up critical data as related > to security. > > Of course, one could also move the whole thing to perl(1), > but right now, i see little benefit. Does seem to have little benefit. Perhaps a bit of inline perl for the ROOTBACKUP bit to start? perl <<'EOL' # do ROOTBACKUP EOL > Regarding the question of what to move where, feedback from other > developers is welcome. I think what should exist in security(8) are things that tell you important information. ROOTBACKUP doesn't ouptut anything like that. l8rZ, -- andrew - http://afresh1.com Instructions are just another man's opinion of how to do something. -- Weldboy #DPWisdom
Remove the freelist member from vm_physseg
The new world order of pmemrange makes this data completely redundant
(being dealt with by the pmemrange constraints instead). Remove all code
that messes with the freelist.
While touching every caller of uvm_page_physload() anyway, add the flags
argument to all callers (all but one is 0 and that one already used
PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
without it.
Should shrink the code a bit, as well.
My machine room is still in a mess, so this has only had the build
testing on i386 and amd64. I'd appreciate if people could check the
others since it'll be a while before I can get all my machines properly
set up.
ok?
-0-
diff --git arch/alpha/alpha/machdep.c arch/alpha/alpha/machdep.c
index 2a5a8de..216a681 100644
--- arch/alpha/alpha/machdep.c
+++ arch/alpha/alpha/machdep.c
@@ -559,7 +559,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", pfn0, kernstartpfn);
#endif
uvm_page_physload(pfn0, kernstartpfn,
- pfn0, kernstartpfn, VM_FREELIST_DEFAULT);
+ pfn0, kernstartpfn, 0);
}
#ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
@@ -573,7 +573,7 @@ nobootinfo:
"0x%lx / 0x%lx\n", kernendpfn, pfn1);
#endif
uvm_page_physload(kernendpfn, pfn1,
- kernendpfn, pfn1, VM_FREELIST_DEFAULT);
+ kernendpfn, pfn1, 0);
}
} else {
/*
@@ -583,8 +583,7 @@ nobootinfo:
printf("Loading cluster %d: 0x%lx / 0x%lx\n", i,
pfn0, pfn1);
#endif
- uvm_page_physload(pfn0, pfn1, pfn0, pfn1,
- VM_FREELIST_DEFAULT);
+ uvm_page_physload(pfn0, pfn1, pfn0, pfn1, 0);
}
#ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
diff --git arch/alpha/include/vmparam.h arch/alpha/include/vmparam.h
index 24fb644..5ff1c06 100644
--- arch/alpha/include/vmparam.h
+++ arch/alpha/include/vmparam.h
@@ -125,9 +125,6 @@
#defineVM_PHYSSEG_STRATVM_PSTRAT_BSEARCH
#defineVM_PHYSSEG_NOADD/* no more after
vm_mem_init */
-#defineVM_NFREELIST1
-#defineVM_FREELIST_DEFAULT 0
-
/*
* pmap-specific data stored in the vm_physmem[] array.
*/
diff --git arch/amd64/amd64/machdep.c arch/amd64/amd64/machdep.c
index 9ca1a7a..bc728a3 100644
--- arch/amd64/amd64/machdep.c
+++ arch/amd64/amd64/machdep.c
@@ -1360,7 +1360,6 @@ init_x86_64(paddr_t first_avail)
for (x = 0; x < mem_cluster_cnt; x++) {
paddr_t seg_start = mem_clusters[x].start;
paddr_t seg_end = seg_start + mem_clusters[x].size;
- int seg_type;
if (seg_start < first_avail) seg_start = first_avail;
if (seg_start > seg_end) continue;
@@ -1368,20 +1367,12 @@ init_x86_64(paddr_t first_avail)
physmem += atop(mem_clusters[x].size);
- /* XXX - Should deal with 4GB boundary */
- if (seg_start >= (1UL<<32))
- seg_type = VM_FREELIST_HIGH;
- else if (seg_end <= 16*1024*1024)
- seg_type = VM_FREELIST_LOW;
- else
- seg_type = VM_FREELIST_DEFAULT;
-
#if DEBUG_MEMLOAD
printf("loading 0x%lx-0x%lx (0x%lx-0x%lx)\n",
seg_start, seg_end, atop(seg_start), atop(seg_end));
#endif
uvm_page_physload(atop(seg_start), atop(seg_end),
- atop(seg_start), atop(seg_end), seg_type);
+ atop(seg_start), atop(seg_end), 0);
}
#if DEBUG_MEMLOAD
printf("avail_start = 0x%lx\n", avail_start);
diff --git arch/amd64/include/vmparam.h arch/amd64/include/vmparam.h
index 494416f..bc22bac 100644
--- arch/amd64/include/vmparam.h
+++ arch/amd64/include/vmparam.h
@@ -110,11 +110,6 @@
#define VM_PHYSSEG_STRAT VM_PSTRAT_BIGFIRST
#define VM_PHYSSEG_NOADD /* can't add RAM after vm_mem_init */
-#defineVM_NFREELIST3
-#defineVM_FREELIST_DEFAULT 0
-#defineVM_FREELIST_LOW 1
-#defineVM_FREELIST_HIGH2
-
#define __HAVE_VM_PAGE_MD
struct pv_entry;
struct vm_page_md {
diff --git arch/armish/armish/armish_machdep.c
arch/armish/armish/armish_machdep.c
index d8ac7f6..850694f 100644
--- arch/armish/armish/armish_machdep.c
+++ arch/armish/armish/armish_machdep.c
@@ -750,8 +750,7 @@ initarm(void *arg)
#endif
uvm_setpagesize(); /* initialize PAGE_SIZE-dependent variables */
uvm_page_physload(atop(physical_freestart), atop(physical_freeend),
- atop(physical_freestart), atop(physical_freeend),
- VM_FREELIST_DEFAULT);
+ atop(phy
kill the unused vm_page_lookup_freelist()
ok?
-0-
diff --git uvm/uvm_page.c uvm/uvm_page.c
index f1b5d04..10ef7d1 100644
--- uvm/uvm_page.c
+++ uvm/uvm_page.c
@@ -1477,23 +1477,6 @@ uvm_pagecopy(struct vm_page *src, struct vm_page *dst)
}
/*
- * uvm_page_lookup_freelist: look up the free list for the specified page
- */
-int
-uvm_page_lookup_freelist(struct vm_page *pg)
-{
-#if VM_PHYSSEG_MAX == 1
- return (vm_physmem[0].free_list);
-#else
- int lcv;
-
- lcv = vm_physseg_find(atop(VM_PAGE_TO_PHYS(pg)), NULL);
- KASSERT(lcv != -1);
- return (vm_physmem[lcv].free_list);
-#endif
-}
-
-/*
* uvm_pagecount: count the number of physical pages in the address range.
*/
psize_t
diff --git uvm/uvm_page.h uvm/uvm_page.h
index 3acbfd1..e131424 100644
--- uvm/uvm_page.h
+++ uvm/uvm_page.h
@@ -256,8 +256,6 @@ voiduvm_pagealloc_pg(struct vm_page *,
struct uvm_object *,
struct uvm_constraint_range; /* XXX move to uvm_extern.h? */
psize_tuvm_pagecount(struct uvm_constraint_range*);
-intuvm_page_lookup_freelist(struct vm_page *);
-
#if VM_PHYSSEG_MAX == 1
/*
* Inline functions for archs like the vax where function calls are expensive.
--
Harris's Lament:
All the good ones are taken.
Re: pciide/wdc ata_drive_datas init refactoring; testers wanted!
On Mon, May 09, 2011 at 12:46:21PM +0100, Stuart Henderson wrote:
> I've tested both these diffs ("Refactor wdc channel_queue
> malloc/initialization" and "pciide/wdc ata_drive_datas init
> refactoring") on the following; no problems noticed and this
> covers two of the special cases in the init refactoring diff.
Awesome, thanks!
Re: Synaptics touchpad
On Sun, May 08, 2011 at 11:16:40AM +0200, Matthieu Herrb wrote: > Hi again, > > I find the mouse emulation code for synaptics touch pads in your patch > really weird. I've tried to understand what it does, and why it > behaves badly for me on the first tap (move the pointer in the upper > right direction every time), but I fail to understand the logic. > > So I've written a different code which produces better results and is > simpler to understand. It computes relative motion events > after the 2nd one, and sends any event with relative motion or button > state changes. > > This is a diff against the pms.c resulting of your previous patch to tech@ > I agree, my implementation weird, your best :-) Thanks. -- Alexandr Shadchin
Re: mixerctl(1) diff: sort output
On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: > On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser > wrote: > > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: > >> * sorted output looks cleaner, prettier; > >> * it's easier to find the variable you're looking for in a sorted > >> output; > >> * hierarchical variable names yet unordered? doesn't make sense; > >> * this way mixerctl's behaviour will be closer to other *ctl programs > >> which output variables in an ordered fashion (audioctl, sysctl, > >> wsconsctl). > > > > these are all matters of opinion, except for "hierarchical variable names" > > which is not technically the case here. > > > > Okay, but what about making mixerctl more similar to other *ctl? > sysctl is a tree, while the mixer is not a tree. It's not either a linear bunch of strings. Sorting it doesn't make much sense imho. Furthermore, sorting mixctl as strings is easy with sort(1) so it's not absolutely necessary; while it would kill the widget order exposed by the driver. -- Alexandre
Re: mixerctl(1) diff: sort output
On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: > On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser > wrote: > > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: > >> * sorted output looks cleaner, prettier; > >> * it's easier to find the variable you're looking for in a sorted > >> output; > >> * hierarchical variable names yet unordered? doesn't make sense; > >> * this way mixerctl's behaviour will be closer to other *ctl programs > >> which output variables in an ordered fashion (audioctl, sysctl, > >> wsconsctl). > > > > these are all matters of opinion, except for "hierarchical variable names" > > which is not technically the case here. > > > > Okay, but what about making mixerctl more similar to other *ctl? *sigh* $ wsconsctl (blah) Permission denied $ usbhidctl usage: (blah) $ ikectl missing argument: $ gpioctl usage: (blah) or how about, what other *ctl program is almost entirely hardware dependent? > >> Before: > > > > note how the controls are grouped (mostly) by "widget". please read > > azalia(4). > > I did notice that. > Unfortunately, I can't access my amd64 machine right now. It has > like 2 to 3 times the amount of variables shown here and I think I saw > some vars there, for which I couldn't figure out by which criteria were they > ordered. > If mixerctl's intention is that the most important thing is the widget, > then the widget's name should've been placed in front. > I tried this just now, putting widget in front, then the mixer class -- > it looks horrible, completely unscannable. > Maybe the mixer class is the most important thing after all, since > this is the most generic thing you can group various widgets by. ok then, why do some devices have 'outputs.dac' yet others have 'inputs.dac'? what is the difference to the user? which is more correct? why? this has been the case since long before azalia(4). if you cannot explain this, then you just don't understand. > > > >> s@d630:0:/usr/src/usr.bin/mixerctl$ mixerctl > >> outputs.hp_source=dac-0:1 > >> outputs.hp_dir=output > >> outputs.hp_boost=off > >> outputs.line-in_source=dac-2:3 > >> outputs.line-in_dir=input > >> outputs.mic_dir=input-vr80 > >> outputs.spkr_source=dac-2:3 > >> outputs.spkr_dir=none > >> outputs.spkr_boost=off > >> inputs.dac-2:3_mute=off > >> inputs.dac-2:3=152,152 > >> inputs.dac-0:1_mute=off > >> inputs.dac-0:1=152,152 > >> inputs.sel_source=mic > >> outputs.sel=126,126 > >> inputs.sel2_source=line-in > >> outputs.sel2=126,126 > >> inputs.sel3_source=sel > >> inputs.sel3_sel=119,119 > >> inputs.sel4_source=sel2 > >> inputs.sel4_sel2=119,119 > >> record.adc-0:1_source=sel3 > >> record.adc-0:1_mute=off > >> record.adc-2:3_source=sel4 > >> record.adc-2:3_mute=off > >> inputs.beep=85 > > > > and at the end are the "pseudo" controls. the ones most people are > > most interested in. so even if the rest of the controls scroll by > > when you do a simple "mixerctl", you see these controls. > > > > Just by looking at these variables, I cannot distinguish which ones are > "pseudo" and which aren't. This is an implementation detail, I think > the user of an interface shouldn't have to care about implementation > details. > I cannot provide any evidence that most people are or are not > interested in those "pseudo" vars, but I thought most of the time > people are interested in something like "play an mp3 file", "watch a > video", simple stuff like that. In this case one would probably be most > interested in outputs, volume controls... as in, 'outputs.master' ... the one that's tied to the keyboard keys on laptops. this is by far the most important, most used mixer control. It's possible to adjust > sorting and output these vars last, by modifying the cmp function. that is ridiculous. > And I can argue that it is still easier to find what you're looking for > when the output is sorted, especially considering that the output of > mixerctl can vary widely between different computers. please do give an example of how sorting them makes "finding what you're looking for" easier. please. and it better be easier than piping through sort/grep. I'll repeat that you cannot rely on 'inputs' or 'outputs' having true meaning. sorry, but you can't. trust me on that one. > >> outputs.hp_sense=plugged > >> outputs.line-in_sense=unplugged > >> outputs.spkr_muters=hp,line-in > >> outputs.master=153,153 > >> outputs.master.mute=off > >> outputs.master.slaves=dac-2:3,dac-0:1 > >> record.volume=0,0 > >> record.volume.mute=off > >> record.volume.slaves=adc-0:1,adc-2:3 > >> > >> After: > >> s@d630:0:/usr/src/usr.bin/mixerctl$ ./mixerctl > >> inputs.beep=85 > >> inputs.dac-0:1=152,152 > >> inputs.dac-0:1_mute=off > >> inputs.dac-2:3=152,152 > >> inputs.dac-2:3_mute=off > >> inputs.sel2_source=line-in > >> inputs.sel3_sel=119,119 > >> inputs.sel3_source=sel > >> inputs.sel4_sel2=119,119 > >> inputs.sel4_source=sel2 > >> inputs.sel_source=mic > >> outputs.hp_boost=off > >> output
Samo 6 dana super poklon uz sve!
Ukoliko ne E>elite viE!e da primate naE!e elektronske poruke, za odjavljivanje sa naE!e e-mailing liste, kliknite ovde. Samo 6 dana poklon uz fitnes! Uz SVAKU porudE>binu iz ove ponude, samo u narednih 6 dana BMI Metar na POKLON! Ponuda vaE>i još samo do nedelje 15.5.2011! BMI Metar vam omoguDava da mnogo lakše pratite napredak u veE>banju! Pogledajte sve proizvode uz POKLON; Samo 6 dana za POKLON! Fitnes akcija Ne gubite vreme, ova jedinstvena ponuda traje još samo 6 dana! Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u našoj poklon igri ili nagradnom kvizu ili se prijavili za e-D asopis Top Shop-a ili nekog od nasih brendo Ponude date u ovom e-mailu vaE>e za porudE>bine upuDene putem Interneta ili broja telefona 021 489 26 60 Ukoliko ne E>elite više da primate naše elektronske poruke, za odjavljivanje sa naše mailing liste molimo kliknite ovde. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08 [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
Re: mixerctl(1) diff: sort output
On Mon, May 9, 2011 at 3:27 AM, Abel Abraham Camarillo Ojeda wrote: > On Sun, May 8, 2011 at 5:32 PM, Sviatoslav Chagaev > wrote: > ... > Am I missing something? > > $ sysctl | sort > /tmp/sysctl_sorted > $ sysctl | cmp -s /tmp/sysctl_sorted /dev/stdin || echo "different"; > different > $ > At the very least, other *ctl don't intermix toplevel nodes, like kern... kern... hw... kern...
Re: mixerctl(1) diff: sort output
On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser wrote: > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: >> * sorted output looks cleaner, prettier; >> * it's easier to find the variable you're looking for in a sorted >> output; >> * hierarchical variable names yet unordered? doesn't make sense; >> * this way mixerctl's behaviour will be closer to other *ctl programs >> which output variables in an ordered fashion (audioctl, sysctl, >> wsconsctl). > > these are all matters of opinion, except for "hierarchical variable names" > which is not technically the case here. > Okay, but what about making mixerctl more similar to other *ctl? >> Before: > > note how the controls are grouped (mostly) by "widget". please read > azalia(4). I did notice that. Unfortunately, I can't access my amd64 machine right now. It has like 2 to 3 times the amount of variables shown here and I think I saw some vars there, for which I couldn't figure out by which criteria were they ordered. If mixerctl's intention is that the most important thing is the widget, then the widget's name should've been placed in front. I tried this just now, putting widget in front, then the mixer class -- it looks horrible, completely unscannable. Maybe the mixer class is the most important thing after all, since this is the most generic thing you can group various widgets by. > >> s@d630:0:/usr/src/usr.bin/mixerctl$ mixerctl >> outputs.hp_source=dac-0:1 >> outputs.hp_dir=output >> outputs.hp_boost=off >> outputs.line-in_source=dac-2:3 >> outputs.line-in_dir=input >> outputs.mic_dir=input-vr80 >> outputs.spkr_source=dac-2:3 >> outputs.spkr_dir=none >> outputs.spkr_boost=off >> inputs.dac-2:3_mute=off >> inputs.dac-2:3=152,152 >> inputs.dac-0:1_mute=off >> inputs.dac-0:1=152,152 >> inputs.sel_source=mic >> outputs.sel=126,126 >> inputs.sel2_source=line-in >> outputs.sel2=126,126 >> inputs.sel3_source=sel >> inputs.sel3_sel=119,119 >> inputs.sel4_source=sel2 >> inputs.sel4_sel2=119,119 >> record.adc-0:1_source=sel3 >> record.adc-0:1_mute=off >> record.adc-2:3_source=sel4 >> record.adc-2:3_mute=off >> inputs.beep=85 > > and at the end are the "pseudo" controls. the ones most people are > most interested in. so even if the rest of the controls scroll by > when you do a simple "mixerctl", you see these controls. > Just by looking at these variables, I cannot distinguish which ones are "pseudo" and which aren't. This is an implementation detail, I think the user of an interface shouldn't have to care about implementation details. I cannot provide any evidence that most people are or are not interested in those "pseudo" vars, but I thought most of the time people are interested in something like "play an mp3 file", "watch a video", simple stuff like that. In this case one would probably be most interested in outputs, volume controls... It's possible to adjust sorting and output these vars last, by modifying the cmp function. And I can argue that it is still easier to find what you're looking for when the output is sorted, especially considering that the output of mixerctl can vary widely between different computers. >> outputs.hp_sense=plugged >> outputs.line-in_sense=unplugged >> outputs.spkr_muters=hp,line-in >> outputs.master=153,153 >> outputs.master.mute=off >> outputs.master.slaves=dac-2:3,dac-0:1 >> record.volume=0,0 >> record.volume.mute=off >> record.volume.slaves=adc-0:1,adc-2:3 >> >> After: >> s@d630:0:/usr/src/usr.bin/mixerctl$ ./mixerctl >> inputs.beep=85 >> inputs.dac-0:1=152,152 >> inputs.dac-0:1_mute=off >> inputs.dac-2:3=152,152 >> inputs.dac-2:3_mute=off >> inputs.sel2_source=line-in >> inputs.sel3_sel=119,119 >> inputs.sel3_source=sel >> inputs.sel4_sel2=119,119 >> inputs.sel4_source=sel2 >> inputs.sel_source=mic >> outputs.hp_boost=off >> outputs.hp_dir=output >> outputs.hp_sense=plugged >> outputs.hp_source=dac-0:1 >> outputs.line-in_dir=input >> outputs.line-in_sense=unplugged >> outputs.line-in_source=dac-2:3 >> outputs.master=153,153 >> outputs.master.mute=off >> outputs.master.slaves=dac-2:3,dac-0:1 >> outputs.mic_dir=input-vr80 >> outputs.sel=126,126 >> outputs.sel2=126,126 >> outputs.spkr_boost=off >> outputs.spkr_dir=none >> outputs.spkr_muters=hp,line-in >> outputs.spkr_source=dac-2:3 >> record.adc-0:1_mute=off >> record.adc-0:1_source=sel3 >> record.adc-2:3_mute=off >> record.adc-2:3_source=sel4 >> record.volume=0,0 >> record.volume.mute=off >> record.volume.slaves=adc-0:1,adc-2:3 > > I do not find this more useful. prettier, perhaps, but not more useful. > in particular, this (further) breaks the widget-wise grouping on some > devices. please read azalia(4), "inputs" and "outputs" is really just > a hint, and making it more precise is much more difficult than adding > sorting to mixerctl ... > Well it doesn't add any new functionality or anything, sure. I'm just trying to improve my user experience. For me, this would be useful because I wouldn't have to append "| sort" to mixerctl every time I use it
Importador Directo - Cámaras Digitales
USD990 Sony SLT-A33 Kit 18-55 mm Tipo SLT, objetivos intercambiables / Sensor CMOS Exmor HD de 14,20 MP efectivos / Tamaño sensor 23,40 x 15,60 mm / Montura Sony SAL - Lentes 18-55 Factor de multiplicación 1,50x / Pantalla TFT de 3,00 pulgadasUSD625 Canon Powershot G12 Tipo compacta, visor óptico / Sensor CCD de 10,00 MP efectivos Objetivo (en 35 mm) 28,0 - 140,0 mm / Zoom 5x (óptico) Soportes compatibles SD Card / MMC, SDHC, MMCplus, HC MMCplus, SDXC / Pantalla TFT de 2,80 pulgadas Cámaras digitales Sony DSC-W330 USD 212 Sony DSC-W350 USD 220 Fuji S2800 USD 345 Panasonic TZ10/ZS7 USD 359
Re: pciide/wdc ata_drive_datas init refactoring; testers wanted!
I've tested both these diffs ("Refactor wdc channel_queue
malloc/initialization" and "pciide/wdc ata_drive_datas init
refactoring") on the following; no problems noticed and this
covers two of the special cases in the init refactoring diff.
i386 (PC Engines Alix, similar to Soekris 5501)
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 4-sector PIO, LBA, 3919MB, 8027712 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
armish (Thecus N2100):
pciide0 at pci0 dev 3 function 0 "CMD Technology SiI3512 SATA" rev 0x01: DMA
pciide0: using irq 29 for native-PCI interrupt
pciide0: port 1: device present, speed: 1.5Gb/s
wd0 at pciide0 channel 1 drive 0:
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd0(pciide0:1:0): using BIOS timings, Ultra-DMA mode 6
amd64 (Supermicro H8SSL):
pciide0 at pci1 dev 14 function 0 "ServerWorks HT-1000 SATA" rev 0x00: DMA
pciide0: using apic 1 int 11 for native-PCI interrupt
pciide0: port 0: device present, speed: 1.5Gb/s
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 30533MB, 62533296 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
pciide0: port 1: PHY offline
pciide0: port 2: PHY offline
pciide0: port 3: PHY offline
pciide1 at pci1 dev 14 function 1 "ServerWorks HT-1000 SATA" rev 0x00
Re: /etc/daily ROOTBACKUP duid patch
Hi,
RD Thrush wrote on Sun, May 08, 2011 at 11:03:32AM -0400:
> I noticed that ROOTBACKUP stopped working when I converted the /altroot
> fstab entry to a disklabel UID. The attached patch seems to work for me
> but I'm sure there's a better way.
Indeed.
The existing code is already scary, and this makes it worse.
Clearly, at least part of daily(8) has to be rewritten in Perl,
and clearly, the ROOTBACKUP handling is part of the part.
However, how exactly that should be done depends on how much
exactly we want to rewrite. I think ROOTBACKUP is the only part
that really requires rewriting, the rest seems reasonably simple
such that i don't see a real problem with using sh(1) for the rest.
If we decide to just rewrite the ROOTBACKUP handling, i'd suggest
simply moving it from daily(8) to security(8). It is functionally
similar to what security(8) already does (consider changelist(5)).
Besides, one might consider backing up critical data as related
to security.
Of course, one could also move the whole thing to perl(1),
but right now, i see little benefit.
Regarding the question of what to move where, feedback from other
developers is welcome.
Yours,
Ingo
> Index: src/etc/daily
> ===
> RCS file: /a8v/pub/cvsroot/OpenBSD/src/etc/daily,v
> retrieving revision 1.71
> diff -u -p -u -p -r1.71 daily
> --- src/etc/daily 23 Apr 2011 19:35:53 - 1.71
> +++ src/etc/daily 8 May 2011 14:39:23 -
> @@ -94,16 +94,33 @@ fi
> # use it as a backup root filesystem to be updated daily.
> next_part "Backing up root filesystem:"
> while [ "X$ROOTBACKUP" = X1 ]; do
> - rootbak=`awk '$2 == "/altroot" && $1 ~ /^\/dev\// && $3 == "ffs" && \
> - $4 ~ /xx/ \
> - { print substr($1, 6) }' < /etc/fstab`
> - if [ -z "$rootbak" ]; then
> - echo "No xx ffs /altroot device found in the fstab(5)."
> - break
> + altroot=`awk '$2 == "/altroot" && $3 == "ffs" && $4 ~ /xx/ \
> + { print }' < /etc/fstab`
> +HAS_DUID=$(echo $altroot | grep -v '^/dev/')
> +if [ "X$HAS_DUID" = "X" ]; then
> + rootbak=`echo $altroot | awk '$2 == "/altroot" && \
> + $1 ~ /^\/dev\// && $3 == "ffs" && \
> + $4 ~ /xx/ \
> + { print substr($1, 6) }'`
> + if [ -z "$rootbak" ]; then
> + echo "No xx ffs /altroot device found in the fstab(5)."
> + break
> + fi
> + bakdisk=${rootbak%[a-p]}
> + sysctl -n hw.disknames | grep -Fqw $bakdisk || break
> + bakpart=${rootbak#$bakdisk}
> + else
> + duidbak=$(echo ${altroot} | cut -d\. -f1)
> + bakpart=$(echo ${altroot} | awk '{print $1}' | cut -d\. -f2)
> + bakdisk=$(sysctl -n hw.disknames | tr "," "\n" \
> + | grep -Fw $duidbak | cut -d: -f1)
> + if [ -z "$bakdisk" ]; then
> + echo "No xx ffs /altroot duid found in the fstab(5)."
> + break
> + fi
> + rootbak="$bakdisk$bakpart"
> + sysctl -n hw.disknames | grep -Fqw $bakdisk || break
> fi
> - bakdisk=${rootbak%[a-p]}
> - sysctl -n hw.disknames | grep -Fqw $bakdisk || break
> - bakpart=${rootbak#$bakdisk}
> baksize=`disklabel $bakdisk 2>/dev/null | \
> awk -v "part=$bakpart:" '$1 == part { print $2 }'`
> rootdev=`mount | awk '$3 == "/" && $1 ~ /^\/dev\// && $5 == "ffs" \
Re: huge relayd diff needs testing
As expressed privately the diff reads fine to me and I like the idea,
it compiles and runs, tentative ok pyr@ for now, but let's wait for
some usage feedback a bit later this week.
On Fri, May 6, 2011 at 9:16 PM, Reyk Floeter wrote:
> On Fri, May 06, 2011 at 08:12:43PM +0200, Reyk Floeter wrote:
>> hi,
>>
>> the following diff needs some serious testing in existing setups.
>> it does not add any new features...
>>
>> ...but it reorganizes, shuffles, and changes the relayd code and
>> internal APIs and it introduces an privsep API that is based on iked
>> and smtpd. why? before i continue working on relayd, i need to sync
>> it to 2011 and clean it up a bit. i also intend to sync the changes
>> in proc.c back to iked. more cleanup and infrastructure changes will
>> follow later and i intend to work on some outstanding issues in
>> relayd. for example, proper reload support will need a rewrite of the
>> existing reload code and even a redesign of some relayd
>> infrastructure... this is the first step.
>>
>> so my main interest is if this diff breaks anything otherwise i will
>> go ahead and commit it after a while.
>>
>> any testers?
>>
>
> i missed the relayctl bit in the previous diff.
>
> Index: usr.sbin/relayctl/relayctl.c
> ===
> RCS file: /cvs/src/usr.sbin/relayctl/relayctl.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 relayctl.c
> --- usr.sbin/relayctl/relayctl.c31 Dec 2010 21:22:42 -
1.42
> +++ usr.sbin/relayctl/relayctl.c6 May 2011 19:13:23 -
> @@ -189,7 +189,7 @@ main(int argc, char *argv[])
>verbose = 2;
>/* FALLTHROUGH */
>case LOG_BRIEF:
> - imsg_compose(ibuf, IMSG_CTL_LOG_VERBOSE, 0, 0, -1,
> + imsg_compose(ibuf, IMSG_CTL_VERBOSE, 0, 0, -1,
>&verbose, sizeof(verbose));
>printf("logging request sent.\n");
>done = 1;
>return;
Re: plug small memory leak in vfwprintf()
On Mon, May 9, 2011 at 1:17 AM, Stefan Sperling wrote: > ok? > > Index: stdio/vfwprintf.c > === > RCS file: /cvs/src/lib/libc/stdio/vfwprintf.c,v > retrieving revision 1.3 > diff -u -p -r1.3 vfwprintf.c > --- stdio/vfwprintf.c 28 Apr 2011 17:38:46 - 1.3 > +++ stdio/vfwprintf.c 8 May 2011 23:12:00 - > @@ -1051,6 +1051,8 @@ overflow: >ret = -1; > > finish: > + if (convbuf) > + free(convbuf); > #ifdef FLOATING_POINT >if (dtoaresult) >__freedtoa(dtoaresult); > > Sure! Ciao, David
Re: Synaptics touchpad
On Sun, 8 May 2011 06:36:46 +0600 Alexandr Shadchin wrote: > Driver xf86-input-synaptics need to build manually: > > update src and xenocara tree > cd /usr/src > make obj includes > cd /usr/xenocara/driver/xf86-input-synaptics > make -f Makefile.bsd-wrapper obj build Looks like it is now linked to build by default, great! Log message: Enable xf86-input-synaptics on i386 and amd64. Thx all! jirib
