Re: Include hostname in shell prompts by default

2017-12-09 Thread Ian Darwin

On 2017-12-09 1:10 PM, Theo de Raadt wrote:

the default prompt works exactly because it doesn;t try to second guess
what the user wants, or what is or isn;t good for them. the mechanism
for changing the prompt is trivial.

i don;t think it makes sense to change the shells in this way.

Having seen bug reports with data from the wrong machine multiple
times in the last year, especially related to Mike's new work in vmm,
I'm sorry I have to disagree.  Some developers have even rebooted
the wrong machines.

Is there anyone who hasn't?

Not everyone has time to configure their development machines
as you suggest.
If it truly can't be fixed in /etc/profile and/or /etc/ksh.kshrc, then 
it should be fixed it in the code.

This change has *no impact* on the people who already take the time
to change their prompt.  It improves the lives of those who don't have
time to do so.


Re: usbtv driver port (questions)

2016-05-25 Thread Ian Darwin

On 2016-05-25 7:57 AM, Marcus Glocker wrote:

On Tue, May 24, 2016 at 04:46:57PM -0700, patrick keshishian wrote:


I have a "mostly working" driver port for Fushicai Audio-Video
Grabber (vendor 0x1b71 product 0x3002).

I've had the video bit working for a few days on amd64 and macppc.
I finally managed to get the audio bit working this morning on
amd64, but still an encoding issue (LE vs BE) on macppc.

2. Return values inside parenthesis or not?

The ongoing religious question :-)  Some people say return and sizeof
shouldn't be used with parenthesis because they are not functions.  I
still find it more readable with parenthesis.  We have both variations
in the tree.  Your choice.

"Obviously without" :-)

3. Original source filenames were hyphenated (e.g., usbtv-video.c).
OK to use underscore instead? I think it is preferred.
(Next question may trump this one)

How's about something a bit shorter, like uvcap.c (USB Video Capture)
and then also call the driver uvcap?  Anyway just a proposal.  Otherwise
yes, replace the '-' by '_' in the filename.

There are (at least) three other popular usb video capture devices with 
totally different chipsets (Syntek, Empia, Somagic, besides this 
Fushicai one, "usbtv007"), so calling one of them uvcap might be 
annoying, like if one of our many network drivers were called "network". 
Does it make sense to start a naming convention like: utvsyn, utvemp, 
utvsom, utvfu, ...?

Myself I own a Syntek one, which is why I'm aware of this issue:
 port 4 addr 3: high speed, power 500 mA, config 1, USB 2.0 Video 
Capture Controller(0x0408), Syntek Semiconductor(0x05e1), rev 0.05

Re: rcctl ls faulty -> failed

2016-03-29 Thread Ian Darwin
On Tue, Mar 29, 2016 at 03:29:27PM +0200, Antoine Jacoutot wrote:
> Hi.
> We'd like to rename the 'faulty' listing to 'failed'.
> i.e. rcctl ls failed
> Index: etc/daily
> ===
> RCS file: /cvs/src/etc/daily,v
> retrieving revision 1.85
> diff -u -p -u -p -r1.85 daily
> --- etc/daily 28 Jan 2016 15:45:34 -  1.85
> +++ etc/daily 29 Mar 2016 13:25:59 -
> @@ -127,7 +127,7 @@ while [ "X$ROOTBACKUP" = X1 ]; do
>  done
>  next_part "Services that should run but don't:"

While you're there, can you please change "should run but don't" to
"should be running but aren't" ? The current wording is awkward,
and also implies that they don't run (ie. they fail to start)
when in fact they may have been running but been shut down
manually, or failed. Language should be precise as well as concise.

Re: ugenctl for attaching USB devices to ugen instead of their specific driver

2015-12-06 Thread Ian Darwin

On 2015-12-06 12:23 PM, Stuart Henderson wrote:

On 2015/12/06 06:02, Mickael Torres wrote:


This is a kernel patch plus a utility called ugenctl I use to allow
selected USB devices to attach as ugen(4) instead of their more specific
driver. My use case is a Microchip "PICkit 2 Microcontroller Programmer"
that attaches as uhid(4), but the command line utility pk2cmd wants a
udev(4) device. There maybe are some other use cases.

If a device is generally pointless with uhid, we can just knock it
out completely in the kernel, see the UQ_BAD_HID mechanism. I think this
applies to your device.

The bigger problem is "dual use" devices; e.g. some want UPS to attach
to upd(4), others want ugen(4) for use with NUT/apcupsd. Your code is
partially useful for these, but because it just changes things at attach,
won't survive a reboot - if it could instead force a device to detach
and reattach to ugen it would help a lot more cases.

One fairly common (I believe) use is with USB printers that attach as ulpt
but CUPS wants as ugen - for these, this is useful as it stands - just 
run it

from rc. Do people want their UPS to sometimes be upd and other times be
a ugen? I can see there might be "I want to change this now" cases, but I
suspect the majority could be done once at each boot and be quite useful.

Re: grep -R without directory argument

2015-04-30 Thread Ian Darwin

On 2015-04-30 04:16, Mark Kettenis wrote:

Date: Thu, 30 Apr 2015 07:51:55 +0200
From: Martin Natano

grep reads from standard input when no files are specified. It also does
so when -R is used, which doesn't really make sense. I think using the
current working directory as a fallback when no directories are
specified would make sense. POSIX says If no file operands are
specified, the standard input shall be used., but -R is an extension
to POSIX, so I guess it is not bound by that.

Far too often I've started a grep -R and waiting for the output, only to
recognize minutes later, that I forgot to add the '.' at the end of the
command and it is reading from stdin.

I do that without the -R option too ;).

Any thoughts? OK?

Not convinced this is an improvement.

Some other *Nixes print a warning in that event, which I find more useful
than grepping a directory I didn't mean. On OS X f'rinstance:

$ grep -r foo
grep: warning: recursive search of stdin

Re: ahci BSY retry

2014-04-23 Thread Ian Darwin
On 2014-04-23 3:50 PM, Chris Cappuccio wrote:
 Peter J. Philipp recently ran into this on his Intel AHCI+Intel SSD
 system (see misc from yesterday):

 ahci2 at pci0 dev 31 function 2 Intel 8 Series AHCI rev 0x05: msi, AHCI 1.3
 ahci2: device on port 1 didn't come ready, TFD: 0x80BSY
 ahci2: stopping the port, softreset slot 31 was still active.
 ahci2: unable to communicate with device on port 1

 I've seen this on boot with Intel AHCI and Transcend SSD and others
 have seen it with Intel AHCI+Intel SSD on soekris net6501.

 Here's a simple fix based on Dragonfly's fix for the same problem.
 (Try to restablish communication one more time.)

Seems to unbreak suspend/resume on my Dell Studio with Intel AHCI (before
your fix it had to be in legacy/ATA mode in the BIOS).

Re: typo security.8

2014-04-22 Thread Ian Darwin
On Tue, Apr 22, 2014 at 06:32:12PM +0200, Henning Brauer wrote:
 * Fritjof Bornebusch [2014-04-22 18:29]:
  it's Trojan horse not Trojan horsed, right?
 a trojan horse.
 the binary has been trojan horsed.

As Henning notes, it was gramatically correct as written (if you are
willing to accept trojan horse as a neologisticized verb), although 
potentially confusing to non-native speakers. I wonder if it
might be better style to say smth like: a trojan-infested binary
or ?

Re: ln -s example

2012-09-20 Thread Ian Darwin

On 12-09-20 8:34 AM, Amit Kulkarni wrote:

This is very helpful. Usually in OpenBSD, you create a symbolic link
/var/www which has limited space and have it point to /home/www where
actual data is stored and which has more space.

This particular example could be

Create a symbolic link named /var/www and point it to /home/www:

  # ln -s /home/www /var/www

A good example is one that actually works.

Since /var/www exists in the default configuration on OpenBSD, your example
will create a symlink in the real /var/ww called www, pointing to 
/home/www, and will never get used.

$ sudo ln -s /home/www /var/www
$ ls -l /var/www/www
lrwxr-xr-x  1 root  daemon  9 Sep 20 12:36 /var/www/www - /home/www

To make it work, you'd have to explain the rationale, show the command 
for moving
the contents (bikeshed warning!), then rmdir /var/www, and finally do 
your symlink.

It's not worth it. Pick a simpler example.

Re: speedup for large binaries with many shared libraries

2011-04-28 Thread Ian Darwin
Makes Eclipse start in 13-14 secs instead of 19. Thanks.

Re: last patch, idea

2011-04-10 Thread Ian Darwin
  while going through my wtmp with last(1) I noticed there could be a better
  way than always gunzip'ing wtmp files and then using last -f.  I've made
  a patch for your consideration that does the following:
  b) it writes the gzipped file to a /tmp location uncompressed so that the
 normal way of operation can be done on the tmp file.
 Having tried to do things like gzcat /var/log/wtmp.0.gz | last -f /dev/stdin
 before, I'd certainly find it useful and this is less intrusive than modifying
 last(8) so it could work with standard input.

Unless you run an extermely large shop like Beck does, or have extremely
tiny disks, why not just remove all the Z flags from newsyslog.conf?
This has the side effect of not having to gunzip /var/log/daemon*  friends.

I guess we inherited this log gzipping from 4BSD, but in those days
a 300MB disk cost a month's salary. Plus another week's salary or so
for the trucking charges.

Re: allow ugen(4) to attach to unused interfaces

2011-01-04 Thread Ian Darwin
On 01/04/11 00:13, Yojiro UO wrote:
 as the ugen(4) is too flexible (and unsafe) than other usb device drivers,
 i don't like this work to extend ugen(4)'s area.
 I know many userland applications which supports multiple platform using
 ugen type interface (because they usually use libusb or ugen apis), but
 it is no reason to support them without considerations.

Here is one very strong consideration: Inasmuch as this change makes
at least some MFC devices just work with CUPS and xsane, for normal
users, without having to e.g., build a custom kernel, I am in favor
of it, unless there is a *specific* risk to other drivers.

Re: no printing cache info

2010-11-28 Thread Ian Darwin
 Best thing would be to print it once per socket, i.e. for the first
 core of each physical CPU.
 Oh, and the flags can be subtly different for other CPUs in the
 system, even if they are exactly the same model, because the BIOS can
 enable/disable some features.

Yes to the first, and the second, also because the repair guy put in a
different chip revision in one socket, or anybody else that had their
fingers inside the case. Per-socket seems like it would be good.

Re: update pms driver

2010-10-07 Thread Ian Darwin
  1) (might or might not be related to pms) When I terminate X and
  try to re-start it (either under XDM or by running sudo startx
  twice), the second X does not always start - it tries, but it hangs
  just after the basket weave background and the X cursor, before any
  apps or the XDM login screen. Other times it works fine.  Since 
  restarting X is not something I normally do (I'm usually the only
  user of this machine, and I usually either suspend or power it off
  when not using), I cannot say if this started when the pms/pmsi
  merger went in. The last time I can be sure that I had several X's
  in a row without rebooting is Sept 20, according to last(1).  So I
  can try triaging (actually we're bisecting, not triaging, when we
  do this :-) ) on the weekend when I am home and have a cvsync repo
  to build multiple kernels against, and time to do so.
  2) (probably related to pms) With wsmoused running, the second X session
  (as above) fails to get /dev/wsmouse. Sadly I captured the wrong
  Xorg.log on this one so I'll have to replicate, but I'm out of time
  for tonight.
 this error does not pms driver, but failure mechanism is similar to 
 one that I found. At first I will finish with pms, and then take over 
 these problems. I think the objection would not be? :)

I really doubt if anyone would object to your fixing problems! :-)

Thanks for your contributions. Keep at it!


Re: merge pms and pmsi + added support for some of mouse

2010-09-21 Thread Ian Darwin
On Wed, Sep 22, 2010 at 03:24:28AM +0600, Alexandr Shadchin wrote:
   Sorry, forgot to fix previous diff. Attached correct diff

The revised version not only works for me (Dell Studio amd64 laptop), but
even cures the bug that the internal trackpad (pms) locks up during 

Re: dhclient-script patch to preserve

2010-04-15 Thread Ian Darwin

patrick keshishian wrote:

I believe there is no good reason for dhclient-script to
override an already existing /etc/ file.

This would not be good for other use cases for dhcp, for example, I often
use my netbook at 3 or more locations in the same day. Why would I want
to enshrine the first one in forever, rather than the 
previous one?

Just make a static copy, say, /etc/resolv.conf.home, and copy that over
when you're at home.

Or, set up a dhcp server at home. Run OpenBSD on your firewall and
it's easy to set up :-) with fixed-address entries in dhcpd.conf.

Re: kernel hacking

2009-12-10 Thread Ian Darwin

Robert Yuri wrote:

I'll learn just reading kernel code ?
so, many night you need to understand it ?

Oh yes. Many.

Re: Novatel Wireless Modem (umsm)

2009-11-13 Thread Ian Darwin

Most of these gadgets need some kind of kick to tell them
I'm done using the vapid Windows install disk you provide,
now please do what I bought you for.  And they of course change their
USB device class and ID when kicked.

Try doing eject cd1 and see if it re-attaches as umsm.

If it does, odds are the DEV_UMASS4 quirk will make it work.

Re: Missing header file in synopsis section of authenticate(3) man page.

2009-07-05 Thread Ian Darwin

Ingo Schwarze wrote:

Hi Jason,

Jason McIntyre wrote on Sun, Jul 05, 2009 at 05:46:06PM +0100:

On Tue, Jun 30, 2009 at 08:56:36AM -0300, Joao Salvatti wrote:

Isn't the header file sys/types.h absent in the manual page

Yes, it is absent, but grepping /usr/share/man/cat3 for types.h
tells me that sys/types.h is not mentioned in a single section 3
manual page.


There's no value getting the wrong answer quickly.

cd /usr/src/lib; find . -name \*.3 | xargs grep 'sys.types.h' | 

wc -l

Anyway, it's on hold til after the unlock.