Re: Comments in source code
On Thu, Apr 23, 2020 at 05:38:40PM -0400, Aisha Tammy wrote: > Thanks a lot for responding, I've had some food so am feeling a lot less > frustrated :D > > > On 4/23/20 12:10 PM, Stuart Henderson wrote: > > > > It's often considered better if code is clear enough to stand by itself, > > keeping comments for the less common cases which can't be figured out > > from reading the code. And that way you aren't at risk of assuming > > But like, not all code is simple enough to understand by just reading it. > Comments can do more than just explain api, they can help explain > how the code itself is working. > I have been reading diff, sdiff diff3 and other string algorithms to > understand > how to make it as fast as their GNU counterparts and they are not the > simplest > to read, even when knowing the actual string algorithms pretty well. > If reading the code isn't enough and you see parts you don't understand, then break those parts. See what happens. Find out why it was done. You might find out that the code at that spot doesn't even work correctly. You might figure out a way to fix it or eliminate it. Perhaps submit a diff. >From your work, you may be able to ask a very specific question. Specific questions are more likely to be answered. If someone knows the answer AND also has the time and desire to help. You may also find that the old way was great back in older versions of OpenBSD, but no longer the best way due to changes in the OS. > > If you aren't already, you should be looking at commit messages from > > where the relevant code was touched. That is often where you'll find the > > explanations you seek. > > > I have been reading them, Commit messages don't explain algorithms very > clearly. > I agree this is a very specific use case but definitely something that could > be improved. > Some of the things I've been considering useful (in this specific scenario > for diff3) > - explanation for merge function, what it does > - in merge function, explain how empty for loop is used, as this is a very > big loop > with a lot of cases > Are you reading commit messages far enough back in time? OpenBSD is a fork of NetBSD. Maybe you will need to go back much further in time to find the commit message or discussion that lead up to today. I strongly support comments, very strongly. But only when needed. Explanations are better coming from someone who can discuss with you or might only be available from you working it out for yourself. This is a volunteer project. Comments don't get compiled, but they do take up space, disk space and bandwidth space. Have fun, work hard and enjoy yourself. There are some excellent threads about these topics in the mailing lists. Chris Bennett
_types.h: increase size of size_t
Following the revalations made by a misc@ poster, I am happy to present the following patch which increases the width of size_t from "long" to "long long", which is twice the width as before, on all platforms. This has the effect of doubling the amount of available memory regardless of the physical capacity installed memory hardware. Additionally, it enables PAE on all 32 bit platforms without incurring performance costs. Index: arch/alpha/include/_types.h === RCS file: /cvs/src/sys/arch/alpha/include/_types.h,v retrieving revision 1.24 diff -u -p -r1.24 _types.h --- arch/alpha/include/_types.h 5 Mar 2018 01:15:24 - 1.24 +++ arch/alpha/include/_types.h 24 Apr 2020 02:26:13 - @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; typedef double __double_t; typedef float __float_t; typedef long __ptrdiff_t; -typedefunsigned long __size_t; +typedefunsigned long long__size_t; typedeflong__ssize_t; #if defined(__GNUC__) && __GNUC__ >= 3 typedef__builtin_va_list __va_list; Index: arch/amd64/include/_types.h === RCS file: /cvs/src/sys/arch/amd64/include/_types.h,v retrieving revision 1.17 diff -u -p -r1.17 _types.h --- arch/amd64/include/_types.h 5 Mar 2018 01:15:25 - 1.17 +++ arch/amd64/include/_types.h 24 Apr 2020 02:26:13 - @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; typedefdouble __double_t; typedeffloat __float_t; typedef long __ptrdiff_t; -typedefunsigned long __size_t; +typedefunsigned long long__size_t; typedeflong__ssize_t; #if defined(__GNUC__) && __GNUC__ >= 3 typedef__builtin_va_list __va_list; Index: arch/arm/include/_types.h === RCS file: /cvs/src/sys/arch/arm/include/_types.h,v retrieving revision 1.19 diff -u -p -r1.19 _types.h --- arch/arm/include/_types.h 5 Mar 2018 01:15:25 - 1.19 +++ arch/arm/include/_types.h 24 Apr 2020 02:26:13 - @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; typedef double __double_t; typedef float __float_t; typedef long __ptrdiff_t; -typedefunsigned long __size_t; +typedefunsigned long long__size_t; typedeflong__ssize_t; #if defined(__GNUC__) && __GNUC__ >= 3 typedef__builtin_va_list __va_list; Index: arch/arm64/include/_types.h === RCS file: /cvs/src/sys/arch/arm64/include/_types.h,v retrieving revision 1.4 diff -u -p -r1.4 _types.h --- arch/arm64/include/_types.h 5 Mar 2018 01:15:25 - 1.4 +++ arch/arm64/include/_types.h 24 Apr 2020 02:26:13 - @@ -121,7 +121,7 @@ typedef unsigned long __psize_t; typedefdouble __double_t; typedeffloat __float_t; typedeflong__ptrdiff_t; -typedefunsigned long __size_t; +typedefunsigned long long__size_t; typedeflong__ssize_t; #if defined(__GNUC__) && __GNUC__ >= 3 typedef__builtin_va_list __va_list; Index: arch/hppa/include/_types.h === RCS file: /cvs/src/sys/arch/hppa/include/_types.h,v retrieving revision 1.26 diff -u -p -r1.26 _types.h --- arch/hppa/include/_types.h 5 Mar 2018 01:15:25 - 1.26 +++ arch/hppa/include/_types.h 24 Apr 2020 02:26:13 - @@ -124,7 +124,7 @@ typedef unsigned long __psize_t; typedef double __double_t; typedef float __float_t; typedef long __ptrdiff_t; -typedefunsigned long __size_t; +typedefunsigned long long__size_t; typedeflong__ssize_t; #if defined(__GNUC__) && __GNUC__ >= 3 typedef__builtin_va_list __va_list; Index: arch/i386/include/_types.h === RCS file: /cvs/src/sys/arch/i386/include/_types.h,v retrieving revision 1.23 diff -u -p -r1.23 _types.h --- arch/i386/include/_types.h 5 Mar 2018 01:15:25 - 1.23 +++ arch/i386/include/_types.h 24 Apr 2020 02:26:13 - @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; typedef long double__double_t; typedef long double__float_t; typedef long __ptrdiff_t; -typedefunsigned long __size_t; +typedefunsigned long long__size_t; typedef
Re: More than 16 partitions
On 2020-04-24 04:45, zeurk...@volny.cz wrote: > Your point is well-taken (though this is just the way mespeaks); yet, > Theo is a native speaker No-one is a native speaker of this made up crap, mecraps
Re: More than 16 partitions
On Thu, Apr 23, 2020 at 10:29:01PM +0200, Francois Pussault wrote: > I agree ; Using more than 10 partitions is rare but in case of NFS or other > network shares of course. > 16 is really enough in my point of view. > I've got to disgree with this one. I'm doing porting work. I yank out all of the directories except /usr/ports itself, using mk.conf. I then also make another partition /usr/ports/mystuff umount /usr/ports/mystuff umount /usr/ports newfs /usr/ports, etc. remount /usr/ports, mkdir /usr/ports/mystuff, remount /usr/ports/mystuff tar xzvf ports.tar.gz into /usr/ports and I can continue on working, without having lost any work I'm still examining. Working with retail equipment at home for a normal desktop. 16 OK Power often fails or hardware fails. Working on a server. Power almost never fails, nor the hardware. At home I run built-in HD, USB flash and USB HD. 16 is no problem with three HD's. I can ro lots of stuff and I need to. I'm not doing any porting at home, only on server hardware. Too tired of reliability issues at home. That's just what I(me)thinks. |-} There be-is-are some very good, cheap, rugged and waterproof USB HD's out there. Very portable(s). Bye, Chris
Re: MIdnight Commander won't run
Here is the output... Script started on Thu Apr 23 19:37:38 2020 ld.so loading: 'mc' exe load offset: 0x18c5 flags mc = 0x0 head mc obj mc has mc as head examining: 'mc' loading: libintl.so.6.0 required by mc flags /usr/local/lib/libintl.so.6.0 = 0x0 obj /usr/local/lib/libintl.so.6.0 has mc as head loading: libc.so.95.1 required by mc flags /usr/lib/libc.so.95.1 = 0x20 obj /usr/lib/libc.so.95.1 has mc as head loading: libssh2.so.9.0 required by mc flags /usr/local/lib/libssh2.so.9.0 = 0x0 obj /usr/local/lib/libssh2.so.9.0 has mc as head loading: libslang.so.16.0 required by mc flags /usr/local/lib/libslang.so.16.0 = 0x0 obj /usr/local/lib/libslang.so.16.0 has mc as head loading: libpthread.so.26.1 required by mc flags /usr/lib/libpthread.so.26.1 = 0x8 obj /usr/lib/libpthread.so.26.1 has mc as head loading: libssl.so.47.6 required by mc flags /usr/lib/libssl.so.47.6 = 0x0 obj /usr/lib/libssl.so.47.6 has mc as head loading: libgmodule-2.0.so.4200.9 required by mc flags /usr/local/lib/libgmodule-2.0.so.4200.9 = 0x88 obj /usr/local/lib/libgmodule-2.0.so.4200.9 has mc as head loading: libcrypto.so.45.5 required by mc flags /usr/lib/libcrypto.so.45.5 = 0x0 obj /usr/lib/libcrypto.so.45.5 has mc as head loading: libm.so.10.1 required by mc flags /usr/lib/libm.so.10.1 = 0x0 obj /usr/lib/libm.so.10.1 has mc as head loading: libz.so.5.0 required by mc flags /usr/lib/libz.so.5.0 = 0x0 obj /usr/lib/libz.so.5.0 has mc as head loading: libcurses.so.14.0 required by mc flags /usr/lib/libcurses.so.14.0 = 0x0 obj /usr/lib/libcurses.so.14.0 has mc as head loading: libutil.so.13.1 required by mc flags /usr/lib/libutil.so.13.1 = 0x0 obj /usr/lib/libutil.so.13.1 has mc as head loading: libglib-2.0.so.4201.2 required by mc flags /usr/local/lib/libglib-2.0.so.4201.2 = 0x8 obj /usr/local/lib/libglib-2.0.so.4201.2 has mc as head loading: libiconv.so.7.0 required by mc flags /usr/local/lib/libiconv.so.7.0 = 0x0 obj /usr/local/lib/libiconv.so.7.0 has mc as head linking dep /usr/lib/libcurses.so.14.0 as child of mc linking dep /usr/lib/libm.so.10.1 as child of mc linking dep /usr/lib/libutil.so.13.1 as child of mc linking dep /usr/lib/libssl.so.47.6 as child of mc linking dep /usr/lib/libcrypto.so.45.5 as child of mc linking dep /usr/lib/libz.so.5.0 as child of mc linking dep /usr/local/lib/libslang.so.16.0 as child of mc linking dep /usr/local/lib/libssh2.so.9.0 as child of mc objname /usr/local/lib/libgmodule-2.0.so.4200.9 is nodelete linking dep /usr/local/lib/libgmodule-2.0.so.4200.9 as child of mc linking dep /usr/local/lib/libintl.so.6.0 as child of mc linking dep /usr/local/lib/libglib-2.0.so.4201.2 as child of mc linking dep /usr/local/lib/libiconv.so.7.0 as child of mc linking dep /usr/lib/libpthread.so.26.1 as child of mc linking dep /usr/lib/libc.so.95.1 as child of mc examining: '/usr/lib/libcurses.so.14.0' examining: '/usr/lib/libm.so.10.1' examining: '/usr/lib/libutil.so.13.1' examining: '/usr/lib/libssl.so.47.6' loading: libcrypto.so.45.5 required by /usr/lib/libssl.so.47.6 linking dep /usr/lib/libcrypto.so.45.5 as child of /usr/lib/libssl.so.47.6 examining: '/usr/lib/libcrypto.so.45.5' examining: '/usr/lib/libz.so.5.0' examining: '/usr/local/lib/libslang.so.16.0' examining: '/usr/local/lib/libssh2.so.9.0' loading: libcrypto.so.45.5 required by /usr/local/lib/libssh2.so.9.0 loading: libz.so.5.0 required by /usr/local/lib/libssh2.so.9.0 loading: libssl.so.47.6 required by /usr/local/lib/libssh2.so.9.0 linking dep /usr/lib/libssl.so.47.6 as child of /usr/local/lib/libssh2.so.9.0 linking dep /usr/lib/libcrypto.so.45.5 as child of /usr/local/lib/libssh2.so.9.0 linking dep /usr/lib/libz.so.5.0 as child of /usr/local/lib/libssh2.so.9.0 examining: '/usr/local/lib/libgmodule-2.0.so.4200.9' loading: libglib-2.0.so.4201.2 required by /usr/local/lib/libgmodule-2.0.so.4200.9 linking dep /usr/local/lib/libglib-2.0.so.4201.2 as child of /usr/local/lib/libgmodule-2.0.so.4200.9 examining: '/usr/local/lib/libintl.so.6.0' loading: libiconv.so.7.0 required by /usr/local/lib/libintl.so.6.0 linking dep /usr/local/lib/libiconv.so.7.0 as child of /usr/local/lib/libintl.so.6.0 examining: '/usr/local/lib/libglib-2.0.so.4201.2' loading: libpthread.so.26.1 required by /usr/local/lib/libglib-2.0.so.4201.2 loading: libiconv.so.7.0 required by /usr/local/lib/libglib-2.0.so.4201.2 loading: libpcre.so.3.0 required by /usr/local/lib/libglib-2.0.so.4201.2 ld.so: mc: can't load library 'libpcre.so.3.0' Killed Script done on Thu Apr 23 19:37:39 2020 > Stuart, > > I'm working on capturing the output. I think I see why you say it needs to > run in a script. > > Thanks for the help! > > Jay > >> On 2020-04-23, Raf Czlonka wrote: >>> Would this by any chance be related to the fact that pcre has been >>> removed from WANTLIB[0][1] but the package still pulls in libpcre? >>> >>> $ ldd /usr/local/bin/mc | grep pcre >>> 1b530c236000 1b530c27c000 rlib 01 0 >>> /usr/local/lib/libpcre.so.3.0 >> >> ldd shows
Re: More than 16 partitions
On 2020-04-23 11:45, zeurk...@volny.cz wrote: "Jan Betlach" wrote: For a non-native English speaker like myself, it is very difficult to read your mestuff... Your point is well-taken (though this is just the way mespeaks); yet, Theo is a native speaker, and he seems to have completely missed the content of merecent responses. Weird, isn't it? Anyway, as this would appear to be quite OT, me'd suggest we continue this (if at all) in private mail... Jan Take care, --zeurkous. Say Hi to Boss Nass for me next time you're in Otoh Gunga. Jordan
Re: More than 16 partitions
On Thu, Apr 23, 2020 at 04:42:53PM -0400, Allan Streib wrote: > > So, can I setup openBSD labels on x86_64 without legacy/GPT partition > > first ? > > IIRC yes you can, as long as you don't need to boot from that disk. Easily confirmed (a few false starts deleted from this transcript): $ uname -a OpenBSD foo.darwinsys.com 6.7 GENERIC.MP#145 amd64 # Here I plugged in a cheap USB device $ dmesg | tail -4 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 sd2 at scsibus4 targ 1 lun 0: removable serial.18a5023805270130 sd2: 3750MB, 512 bytes/sector, 768 sectors # Trash any existing fdisk and disklabel info # dd if=/dev/random of=/dev/rsd2c bs=512 count=100 100+0 records in 100+0 records out 51200 bytes transferred in 0.068 secs (742845 bytes/sec) # disklabel sd2 # /dev/rsd2c: type: SCSI disk: SCSI disk label: Store n Go Drive duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 478 total sectors: 768 boundstart: 0 boundend: 768 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 7680 unused i: 7679944 56 MSDOS # fdisk sd2 # confirm there is no fdisk table, just random rubbish Disk: sd2 geometry: 478/255/63 [768 Sectors] Offset: 0 Signature: 0x111 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 82 77157 27 55 - 172421 98 24 [ 1239528960: 1530420603 ] Linux swap 1: 64 10096 3 23 - 176047 141 26 [ 162192451: 2666011513 ] NetWare 2.xx 2: 6E 252409 74 42 - 209458 117 56 [ 4054955288: 3604962205 ] 3: A9 19978 12 42 - 22375 228 62 [ 320947367:38521434 ] NetBSD # disklabel -E sd2 Label editor (enter '?' for help at any prompt) sd2> p OpenBSD area: 0-768; size: 768; free: 768 #size offset fstype [fsize bsize cpg] c: 7680 unused sd2> a partition: [a] offset: [0] 64 size: [7679936] 100M FS type: [4.2BSD] sd2*> w sd2> q No label changes. # newfs /dev/rsd2a /dev/rsd2a: 101.9MB in 208768 sectors of 512 bytes 4 cylinder groups of 25.48MB, 1631 blocks, 3328 inodes each super-block backups (for fsck -b #) at: 32, 52224, 104416, 156608, # mount /dev/sd2a /mnt $ ls /mnt $ date | doas dd of=/mnt/date.txt 0+1 records in 0+1 records out 29 bytes transferred in 0.000 secs (322584 bytes/sec) $ ls /mnt date.txt $ cat /mnt/date.txt Thu Apr 23 18:55:35 EDT 2020 # fdisk sd2 # still no fdisk table Disk: sd2 geometry: 478/255/63 [768 Sectors] Offset: 0 Signature: 0x111 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 82 77157 27 55 - 172421 98 24 [ 1239528960: 1530420603 ] Linux swap 1: 64 10096 3 23 - 176047 141 26 [ 162192451: 2666011513 ] NetWare 2.xx 2: 6E 252409 74 42 - 209458 117 56 [ 4054955288: 3604962205 ] 3: A9 19978 12 42 - 22375 228 62 [ 320947367:38521434 ] NetBSD # So: I was able to newfs, mount, and use an OpenBSD partition which disklabel called 'a' and which had no trace of an fdisk partition around it. As Allan pointed out, this is not for booting from - none of those fdisk partitions looks very healthy.
Re: Comments in source code
Thanks a lot for responding, I've had some food so am feeling a lot less frustrated :D > On 4/23/20 12:10 PM, Stuart Henderson wrote: > > It's often considered better if code is clear enough to stand by itself, > keeping comments for the less common cases which can't be figured out > from reading the code. And that way you aren't at risk of assuming But like, not all code is simple enough to understand by just reading it. Comments can do more than just explain api, they can help explain how the code itself is working. I have been reading diff, sdiff diff3 and other string algorithms to understand how to make it as fast as their GNU counterparts and they are not the simplest to read, even when knowing the actual string algorithms pretty well. > something which is implied by the comment but isn't actually in the code > (either never was, or the code changed but the comment didn't keep up). > And about comments being left behind in code changing, I feel like that is easily changed by people making sure that they also read comments while coding. I don't think that is a good enough excuse about not commenting. > If you aren't already, you should be looking at commit messages from > where the relevant code was touched. That is often where you'll find the > explanations you seek. > I have been reading them, Commit messages don't explain algorithms very clearly. I agree this is a very specific use case but definitely something that could be improved. Some of the things I've been considering useful (in this specific scenario for diff3) - explanation for merge function, what it does - in merge function, explain how empty for loop is used, as this is a very big loop with a lot of cases IMO, any function with a lot of cases should have a small explanation about what it is doing, so the code is a lot more lit. Cheers, Aisha
Re: Comments in source code
On Thu, Apr 23, 2020, at 5:38 PM, Aisha Tammy wrote: > > If you aren't already, you should be looking at commit messages from > > where the relevant code was touched. That is often where you'll find the > > explanations you seek. > > > I have been reading them, Commit messages don't explain algorithms very > clearly. > I agree this is a very specific use case but definitely something that > could be improved. > Some of the things I've been considering useful (in this specific > scenario for diff3) > - explanation for merge function, what it does > - in merge function, explain how empty for loop is used, as this is a > very big loop > with a lot of cases > > IMO, any function with a lot of cases should have a small explanation > about what it > is doing, so the code is a lot more lit. > > Cheers, > Aisha I am no expert on reading code myself, but wouldn't be possible to look at who wrote that bit of code find their email address and ask them? There might not be a simple terse explanation that would go well in comments.
Re: More than 16 partitions
> > From: Strahil Nikolov > Sent: Thu Apr 23 22:16:41 CEST 2020 > To: , Theo de Raadt , > > Cc: Martin Schröder > Subject: Re: More than 16 partitions > > > On April 23, 2020 10:46:44 PM GMT+03:00, Theo de Raadt > wrote: > >You need to stop making this mailing list just about you. > > > >STFU. > > > > > > wrote: > > > >> "Martin Schröder" wrote: > >> > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : > >> >> No problem. Would it be too crude a suggestion that we go back to > >the > >> >> content now...? > >> > > >> > You didn't provide any patch. > >> > >> That is entirely correct. > >> > >> --zeurkous. > >> > >> -- > >> Friggin' Machines! > >> > > Some of these e-mails were useful others not... > > So, can I setup openBSD labels on x86_64 without legacy/GPT partition first ? > And who the hell needs more than 16 partitions ? Why not we just port ZFS > from FreeBSD, or LVM from Linux and get over it ? hello, I agree ; Using more than 10 partitions is rare but in case of NFS or other network shares of course. 16 is really enough in my point of view. > > P.S.: The last one was not a real question, but I would like to hear if > anyone has attempted to port any of these 2 . > > Best Regards, > Strahil Nikolov > Cordialement Francois Pussault 10 chemin de négo saoumos apt 202 - bat 2 31300 Toulouse +33 6 17 230 820 fpussa...@contactoffice.fr
Re: More than 16 partitions
On Thu, Apr 23, 2020 at 08:14:25PM +0200, Jan Betlach wrote: > For a non-native English speaker like myself, it is very difficult to read > your mestuff… One may practice by reading Gollum/Smeagol-passages..
Re: timegm()
Todd C. Miller wrote: > On Wed, 22 Apr 2020 21:21:28 -0600, "Todd C. Miller" wrote: > > > That's fine with me. Those interfaces appeared in SunOS 4.0 according > > to tzcode (which is where we got them from). They did *not* originate > > in NetBSD. I've verified that they were present in SunOS 4.1.3U1, > > though that code appears to be derived from tzcode too. > > Bit Savers has scans of the SunOS 4.0 print manuals which includes > a hard-copy of the man pages. Here you can see that timegm() and > timelocal() were present in SunOS in 1987: > > archive.org/details/bitsavers_sunsunos4.erenceManual198805_78292584/page/n823/mode/2up > > However, they are not present in SunOS 3.5. You can see the list > of library functions from intro(3) which includes gmtime(3) and > localtime(3) but not their inverses: > > https://archive.org/details/bitsavers_sunsunos3.eManualInsertionPagesforRelease3.5198711_7929431/page/n145/mode/2up > > So I think it is safe to say that those interfaces originated in > SunOS 4.0 and not an earlier version. I believe it.
Re: timegm()
On Wed, 22 Apr 2020 21:21:28 -0600, "Todd C. Miller" wrote: > That's fine with me. Those interfaces appeared in SunOS 4.0 according > to tzcode (which is where we got them from). They did *not* originate > in NetBSD. I've verified that they were present in SunOS 4.1.3U1, > though that code appears to be derived from tzcode too. Bit Savers has scans of the SunOS 4.0 print manuals which includes a hard-copy of the man pages. Here you can see that timegm() and timelocal() were present in SunOS in 1987: archive.org/details/bitsavers_sunsunos4.erenceManual198805_78292584/page/n823/mode/2up However, they are not present in SunOS 3.5. You can see the list of library functions from intro(3) which includes gmtime(3) and localtime(3) but not their inverses: https://archive.org/details/bitsavers_sunsunos3.eManualInsertionPagesforRelease3.5198711_7929431/page/n145/mode/2up So I think it is safe to say that those interfaces originated in SunOS 4.0 and not an earlier version. - todd
Re: More than 16 partitions
For a non-native English speaker like myself, it is very difficult to read your mestuff… Jan On 23 Apr 2020, at 19:47, zeurk...@volny.cz wrote: theo wrote: That is a rewriting of history. It's history the way meknows it. Mecertainly predates some of it. The disklabel format predates the PC. Indeed. Mewasn't sure where and when exactly it appeared, so meleft that bit out. But medid know it was older, and metried to communicate that fact (obviously mefailed -- meapologizes). It came from the the ancient attempt to handle things in CSRG's 4.3reno/4.4 work on the hp300. It was probably a rewrite of the native HPUX disk format. Hmm, hp300, eh? This was then put on all the other architectures, as a unified view of the disk. It was modified and extended on as as-needed basis. Rewriting the history like this is pathetic inaccurate and narrowminded. Your history is absolutely false and you've made up a bunch of balony. So, what did memake up? Did mepresent a timeline? An exact order of events? Did mepresent a scientific study? Or didmejust try to give an overview of things in terms that Groot (and many others, mesuspects) may just understand? It is not true, and even a elementary review of the history of disklabel.h back into the early NetBSD tree will make it clear what's going on. Like mesaid, it's the history the way meknows it. Me's not a bloody authority on the history of either BSD or the IBM pee-cee, *at all*. Perhaps meshould've made that clearer. OH, and I did most of the early work post-CSRG, because we needed to "emulate" this on SunOS, and I ported Torek's sparc code into NetBSD. Mehas _no doubt at all_ that you know BSD (including its history) better than me (that is, of course, an understatement). I urge you to stop posting such balony. Then it's me turn to urge you to not read me overview as an historical account of any exactness. After all, the goal, for me, was trying to help Groot understand the relationships he sought clarification for. Perhaps meindeed should've included a disclaimer. Then again, mehas no offical role here (nor does mewant one), and in no way are me words to be taken for the one and universal truth. Can we please just assume that Groot is mature enough to be able to form his own view based on our individual contributions? Me'd like that. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
On Thu, Apr 23, 2020, at 4:16 PM, Strahil Nikolov wrote: > So, can I setup openBSD labels on x86_64 without legacy/GPT partition > first ? > And who the hell needs more than 16 partitions ? Why not we just port > ZFS from FreeBSD, or LVM from Linux and get over it ? > > P.S.: The last one was not a real question, but I would like to hear > if anyone has attempted to port any of these 2 . ZFS cannot be ported to OBSD. It has an unacceptable license. If something like it were to be used on OBSD it would have to be written from scratch with a BSD license and it has already been discussed at length on this list how hard that is. Besides it is not really necessary. ZFS is overly complex and not needed in most cases.
Re: More than 16 partitions
> So, can I setup openBSD labels on x86_64 without legacy/GPT partition first ? IIRC yes you can, as long as you don't need to boot from that disk. Allan
Re: More than 16 partitions
On April 23, 2020 10:46:44 PM GMT+03:00, Theo de Raadt wrote: >You need to stop making this mailing list just about you. > >STFU. > > > wrote: > >> "Martin Schröder" wrote: >> > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : >> >> No problem. Would it be too crude a suggestion that we go back to >the >> >> content now...? >> > >> > You didn't provide any patch. >> >> That is entirely correct. >> >> --zeurkous. >> >> -- >> Friggin' Machines! >> Some of these e-mails were useful others not... So, can I setup openBSD labels on x86_64 without legacy/GPT partition first ? And who the hell needs more than 16 partitions ? Why not we just port ZFS from FreeBSD, or LVM from Linux and get over it ? P.S.: The last one was not a real question, but I would like to hear if anyone has attempted to port any of these 2 . Best Regards, Strahil Nikolov
Re: More than 16 partitions
You need to stop making this mailing list just about you. STFU. wrote: > "Martin Schröder" wrote: > > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : > >> No problem. Would it be too crude a suggestion that we go back to the > >> content now...? > > > > You didn't provide any patch. > > That is entirely correct. > > --zeurkous. > > -- > Friggin' Machines! >
RE: More than 16 partitions
"Martin Schröder" wrote: > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : >> No problem. Would it be too crude a suggestion that we go back to the >> content now...? > > You didn't provide any patch. That is entirely correct. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : > No problem. Would it be too crude a suggestion that we go back to the > content now...? You didn't provide any patch.
RE: More than 16 partitions
"Christian Groessler" wrote: > On 4/23/20 7:57 PM, zeurk...@volny.cz wrote: > >> theo wrote: >>> You made it all up. >> That's an easy accusation, with an easy response: No, medid not make any >> of it up > > > Could you refrain from using your idiotic "me.."-words? Fine, me'll try and keep the idiotic ones out. > Thanks No problem. Would it be too crude a suggestion that we go back to the content now...? --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
On 4/23/20 7:57 PM, zeurk...@volny.cz wrote: theo wrote: You made it all up. That's an easy accusation, with an easy response: No, medid not make any of it up Could you refrain from using your idiotic "me.."-words? Thanks
RE: More than 16 partitions
"Jan Betlach" wrote: > For a non-native English speaker like myself, it is very difficult to > read your mestuff... Your point is well-taken (though this is just the way mespeaks); yet, Theo is a native speaker, and he seems to have completely missed the content of merecent responses. Weird, isn't it? Anyway, as this would appear to be quite OT, me'd suggest we continue this (if at all) in private mail... > Jan Take care, --zeurkous. -- Friggin' Machines!
Re: relayd + httpd + Django/Rails?
Now I feel dumb. Didn't need relayd at all - just the "fastcgi" option inside a
httpd server block.
Jesus christ.
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday 23. April 2020 kl. 04:17, Joe Ansbach
wrote:
> Hi,
>
> I got this VPS here where I'm hosting a bunch of static sites for friends and
> family with httpd (Let's Encrypt). Now, however, I've agreed to host a bunch
> of Django (Unicorn) and Rails (Puma) apps as well, and I'm starting to think
> maybe I've bitten off more than I can chew.
>
> Am I on the right path here? Would anybody mind giving me a nudge in the
> right direction?
>
> ++--+-+--+
> Internet | pf | relayd | httpd | staticsite1.com:8000 |
> | | (80/443) | | staticsite2.com:8000 |
> | | | | staticsite3.com:8000 |
> | | | | staticsite4.com:8000 |
> | | | +--+
> | | | Unicorn | djangoapp1.com:7001 |
> | | | | djangoapp2.com:7002 |
> | | | +--+
> | | | Puma | railsapp1.com:6001 |
> | | | | railsapp2.com:6002 |
> ++--+-+--+
>
> -
>
> /etc/pf.conf
>
> =
>
> pass in on $ext_if inet proto tcp from any to $ext_if port { 80, 443 } keep
> state
>
>
>
> /etc/relayd.conf
>
> =
>
> my_ip="127.0.0.1"
> relayd_port="80"
>
> table { $my_ip }
> table { $my_ip }
> table { $my_ip }
>
> http protocol "httpfilter" {
> tcp { nodelay, sack, backlog 128 }
>
> return error
>
> match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
> match header set "X-Forwarded-For" value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
> }
>
> relay "reverseproxy" {
> listen on $my_ip port $relayd_port
>
> protocol "httpfilter"
>
> forward to port 8000
> forward to port 7001
> forward to port 7002
> forward to port 6001
> forward to port 6002
>
> }
>
> --
>
> /etc/httpd.conf
>
>
>
> server "staticsite1.com" {
> listen on * port 8000
> root "/htdocs/staticsite1.com"
> [...]
> }
>
> server "staticsite1.com" {
> listen on * tls port 443
> root "/htdocs/staticsite1.com"
> [...]
> }
>
> [...]
>
> -
>
> Thanks, Joe
RE: More than 16 partitions
theo wrote: > You made it all up. That's an easy accusation, with an easy response: No, medid not make any of it up. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
You made it all up. wrote: > theo wrote: > > That is a rewriting of history. > > It's history the way meknows it. Mecertainly predates some of it. > > > The disklabel format predates the PC. > > Indeed. Mewasn't sure where and when exactly it appeared, so meleft that > bit out. But medid know it was older, and metried to communicate that > fact (obviously mefailed -- meapologizes). > > > It came from the the ancient attempt to handle things in CSRG's > > 4.3reno/4.4 work on the hp300. It was probably a rewrite of the > > native HPUX disk format. > > Hmm, hp300, eh? > > > This was then put on all the other architectures, as a unified > > view of the disk. It was modified and extended on as as-needed > > basis. > > > > Rewriting the history like this is pathetic inaccurate and > > narrowminded. Your history is absolutely false and you've made > > up a bunch of balony. > > So, what did memake up? Did mepresent a timeline? An exact order of > events? Did mepresent a scientific study? Or didmejust try to give an > overview of things in terms that Groot (and many others, mesuspects) may > just understand? > > > It is not true, and even a elementary > > review of the history of disklabel.h back into the early NetBSD > > tree will make it clear what's going on. > > Like mesaid, it's the history the way meknows it. Me's not a bloody > authority on the history of either BSD or the IBM pee-cee, *at all*. > > Perhaps meshould've made that clearer. > > > OH, and I did most of the early work post-CSRG, because we needed > > to "emulate" this on SunOS, and I ported Torek's sparc code into > > NetBSD. > > Mehas _no doubt at all_ that you know BSD (including its history) better > than me (that is, of course, an understatement). > > > I urge you to stop posting such balony. > > Then it's me turn to urge you to not read me overview as an historical > account of any exactness. > > After all, the goal, for me, was trying to help Groot understand the > relationships he sought clarification for. > > Perhaps meindeed should've included a disclaimer. Then again, mehas no > offical role here (nor does mewant one), and in no way are me words to > be taken for the one and universal truth. > > Can we please just assume that Groot is mature enough to be able to form > his own view based on our individual contributions? > > Me'd like that. > > --zeurkous. > > -- > Friggin' Machines!
RE: More than 16 partitions
theo wrote: > That is a rewriting of history. It's history the way meknows it. Mecertainly predates some of it. > The disklabel format predates the PC. Indeed. Mewasn't sure where and when exactly it appeared, so meleft that bit out. But medid know it was older, and metried to communicate that fact (obviously mefailed -- meapologizes). > It came from the the ancient attempt to handle things in CSRG's > 4.3reno/4.4 work on the hp300. It was probably a rewrite of the > native HPUX disk format. Hmm, hp300, eh? > This was then put on all the other architectures, as a unified > view of the disk. It was modified and extended on as as-needed > basis. > > Rewriting the history like this is pathetic inaccurate and > narrowminded. Your history is absolutely false and you've made > up a bunch of balony. So, what did memake up? Did mepresent a timeline? An exact order of events? Did mepresent a scientific study? Or didmejust try to give an overview of things in terms that Groot (and many others, mesuspects) may just understand? > It is not true, and even a elementary > review of the history of disklabel.h back into the early NetBSD > tree will make it clear what's going on. Like mesaid, it's the history the way meknows it. Me's not a bloody authority on the history of either BSD or the IBM pee-cee, *at all*. Perhaps meshould've made that clearer. > OH, and I did most of the early work post-CSRG, because we needed > to "emulate" this on SunOS, and I ported Torek's sparc code into > NetBSD. Mehas _no doubt at all_ that you know BSD (including its history) better than me (that is, of course, an understatement). > I urge you to stop posting such balony. Then it's me turn to urge you to not read me overview as an historical account of any exactness. After all, the goal, for me, was trying to help Groot understand the relationships he sought clarification for. Perhaps meindeed should've included a disclaimer. Then again, mehas no offical role here (nor does mewant one), and in no way are me words to be taken for the one and universal truth. Can we please just assume that Groot is mature enough to be able to form his own view based on our individual contributions? Me'd like that. --zeurkous. -- Friggin' Machines!
Re: More than 16 partitions
That is a rewriting of history. The disklabel format predates the PC. It came from the the ancient attempt to handle things in CSRG's 4.3reno/4.4 work on the hp300. It was probably a rewrite of the native HPUX disk format. This was then put on all the other architectures, as a unified view of the disk. It was modified and extended on as as-needed basis. Rewriting the history like this is pathetic inaccurate and narrowminded. Your history is absolutely false and you've made up a bunch of balony. It is not true, and even a elementary review of the history of disklabel.h back into the early NetBSD tree will make it clear what's going on. OH, and I did most of the early work post-CSRG, because we needed to "emulate" this on SunOS, and I ported Torek's sparc code into NetBSD. I urge you to stop posting such balony. wrote: > "Groot" wrote: > > I've tried and failed to create more than 16 > > partitions on OpenBSD. First of all I don't > > understand the difference between the operations > > performed by fdisk and disklabel. Is it that > > OpenBSD sees partitions differently? First we > > create an OpenBSD partition with fdisk and then > > with disklabel we can create at the most 16 more > > filesystem partitions within it. > > Traditionally, BSD has used only its own disklabel(5). Unfortunately, > mess-dos on the IBM pee-cee set a competing standard, the "Master Boot > Record", with a separate partition table (and a lot of kludging to > support more than 4 partitions). While it was (and AFAIK remains) > possible to use the whole disk the traditional way (only a BSD > disklabel, as on e.g. sparc64), it has become common practice to wrap > the BSD stuff in a mess-dos partition, with the caveat that some of the > mess-dos partition entries are duplicated in the BSD label. > > Thus, the BSD label is essentially OpenBSD's version of the structure of > things on the disk. But is an imperfect version: 16 partitions *is* the > limit for an OpenBSD label, and, of course, mess-dos partition > identifiers (which are more *ahem* fine-grained) are not used. To top it > off, partitions which rest within the mess-dos OpenBSD partition are not > necessarily represented on the mess-dos level (this would count, from > the mess-dos perspective, as overlap between partitions and thus confuse > a great many tools). > > Then GPT entered the story to make the mess complete. But me'll remain > blissfully unaware of the inner workings of that particular clusterfsck, > if you don't mind ;) > > It's no shame to be confused by this garbage. Almost all of us'd like > better, but for the above hysterical raisins, it's not so easy to make > it so. > > --zeurkous. > > -- > Friggin' Machines! >
Re: booting from a SD card on APU2: ERR R
On Apr 23 17:51:42, h...@stare.cz wrote: > After the flash, I removed the USB stick > and the APU booted from the SD card > - only to panic later when the SD card "disappeared"; > it was not even offered on the next boot, nor was it > seen at the next USB boot to be reinstalled on. > > So I suspect the media: > > On Apr 23 06:55:16, we...@weirdnet.nl wrote: > > On Wed, Apr 22, 2020 at 11:54:22PM +0200, Jan Stary wrote: > > | Booting from Hard Disk... > > | Using drive 0, partition 3. > > | Loading > > | ERR R > > > > These "ERR x" error codes are documented in biosboot(8)[1]. They're > > brief because the biosboot program is quite space constrained. In > > this particular case, "ERR R", the documentation says: > > > > >ERR RRead error. The BIOS returned an error indication when > > > biosboot > > > attempted to read a disk sector. This might be any media > > > error, > > > including bad sectors (common on floppy disks), and invalid > > > sectors (can occur with bad geometry translations). > > Indeed, the SD card took three inserts on another machine to appear. > I will try with another one and get back. Sure enough, with a decent SD card, everything works just fine. Thanks again. Jan
RE: More than 16 partitions
"Groot" wrote: > I've tried and failed to create more than 16 > partitions on OpenBSD. First of all I don't > understand the difference between the operations > performed by fdisk and disklabel. Is it that > OpenBSD sees partitions differently? First we > create an OpenBSD partition with fdisk and then > with disklabel we can create at the most 16 more > filesystem partitions within it. Traditionally, BSD has used only its own disklabel(5). Unfortunately, mess-dos on the IBM pee-cee set a competing standard, the "Master Boot Record", with a separate partition table (and a lot of kludging to support more than 4 partitions). While it was (and AFAIK remains) possible to use the whole disk the traditional way (only a BSD disklabel, as on e.g. sparc64), it has become common practice to wrap the BSD stuff in a mess-dos partition, with the caveat that some of the mess-dos partition entries are duplicated in the BSD label. Thus, the BSD label is essentially OpenBSD's version of the structure of things on the disk. But is an imperfect version: 16 partitions *is* the limit for an OpenBSD label, and, of course, mess-dos partition identifiers (which are more *ahem* fine-grained) are not used. To top it off, partitions which rest within the mess-dos OpenBSD partition are not necessarily represented on the mess-dos level (this would count, from the mess-dos perspective, as overlap between partitions and thus confuse a great many tools). Then GPT entered the story to make the mess complete. But me'll remain blissfully unaware of the inner workings of that particular clusterfsck, if you don't mind ;) It's no shame to be confused by this garbage. Almost all of us'd like better, but for the above hysterical raisins, it's not so easy to make it so. --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
Haai, theo wrote: > Groot wrote: > >> I've tried and failed to create more than 16 >> partitions on OpenBSD. First of all I don't >> understand the difference between the operations >> performed by fdisk and disklabel. Is it that >> OpenBSD sees partitions differently? First we >> create an OpenBSD partition with fdisk and then >> with disklabel we can create at the most 16 more >> filesystem partitions within it. >> >> But if I want more than 16 filesystem partitions >> on a single disk naturally I try to create more >> fdisk partitions and then within it lay more fs- >> partitions. When I try that OpenBSD doesn't >> recognize those partitions and I can't even run >> 'newfs' on those partitions. Is there a way for >> OpenBSD to deal with more than 16 partitions? >> > > Sorry, there is no way. > > You can create a vnd, on a file, and then that vnd can contain > partitions. But it might suck. Me's configured a pair of consecutive softraid(4) partitions in concat mode. Sees relatively light use, but performance has been adequate. Previously, meused crypto w/ a passphrase of '0' (automagically read from a file at boot), but that was just needlessly complicated. Fixing vnd(4) to work on devices, or just adding a 'concat-of-1-volume' (perhaps call it 'L'ayer) "level" to softraid, is what me'd recommend. But that doesn't seem to help Groot (right now). Hope the above helps, --zeurkous. -- Friggin' Machines!
connect(2) on unix domain sockets
The code below fails connect(2) with errno set to ECONNREFUSED.
The [1] says: “If the connection cannot be established immediately and
O_NONBLOCK is not set for the file descriptor for the socket, connect() shall
block for up to an unspecified timeout interval until the connection is
established.”
Also [1] describes “ECONNREFUSED” error as "The target address was not
listening for connections or refused the connection request."
On some UNIXes connect(2) doesn’t fail, on some (especially BSD) it does.
Code below has only 2 simultaneous connection attempts but backlog is
1.
Is this a bug or implementation specific behaviour?
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html
cut begin
#include
#include
#include
#include
#include
#include
#include
int main(void)
{
int s;
struct sockaddr_un sun;
size_t i;
if((s=socket(AF_UNIX, SOCK_STREAM, 0))<0){
err(1, "socket()");
}
memset(, 0, sizeof(sun));
sun.sun_len=sizeof(sun);
sun.sun_family=AF_UNIX;
snprintf(sun.sun_path, sizeof(sun.sun_path)-1,
"/tmp/socket%d", getpid());
if(bind(s, (struct sockaddr *), sizeof(sun))<0){
err(1, "bind()");
}
if(listen(s, 1)<0){
err(1, "listen()");
}
for(i=0; i<2; ++i){
switch(fork()){
case -1:
err(1, "fork()");
case 0:
close(s);
while(1){
if((s=socket(AF_UNIX, SOCK_STREAM, 0))<0){
err(1, "socket(conn)");
}
if(connect(s, (struct sockaddr *),
sizeof(sun))<0){
#if 1
warn("connect()");
#endif
}
close(s);
}
break;
default:
break;
}
}
while(1){
int sc;
if((sc=accept(s, NULL, NULL))<0){
err(1, "accept()");
}
close(sc);
}
return 0;
}
cut end
Re: More than 16 partitions
Groot wrote: > I've tried and failed to create more than 16 > partitions on OpenBSD. First of all I don't > understand the difference between the operations > performed by fdisk and disklabel. Is it that > OpenBSD sees partitions differently? First we > create an OpenBSD partition with fdisk and then > with disklabel we can create at the most 16 more > filesystem partitions within it. > > But if I want more than 16 filesystem partitions > on a single disk naturally I try to create more > fdisk partitions and then within it lay more fs- > partitions. When I try that OpenBSD doesn't > recognize those partitions and I can't even run > 'newfs' on those partitions. Is there a way for > OpenBSD to deal with more than 16 partitions? > Sorry, there is no way. You can create a vnd, on a file, and then that vnd can contain partitions. But it might suck.
Re: Comments in source code
On 2020-04-23, Aisha Tammy wrote: > Hey devs and all, > I'm kind of new to OpenBSD, only working on ports so far so take > what I say with chill. > I've been reading the source code in GIT and felt a real lack of comments > explaining what the code is doing. Is this something encouraged in obsd? > I would really like to have something more than super condensed one line > explanations like in style(9). > > Just wanted to express my frustration and also to ask if there is any > better way to understand how the code is working? I feel like this > would deter a lot of new contributors, me including. > > Hopefully I don't sound too negative. I'm willing to send patches which > just add comments and explanations, if there is any interest from the devs. > > Best, > Aisha > > It's often considered better if code is clear enough to stand by itself, keeping comments for the less common cases which can't be figured out from reading the code. And that way you aren't at risk of assuming something which is implied by the comment but isn't actually in the code (either never was, or the code changed but the comment didn't keep up). If you aren't already, you should be looking at commit messages from where the relevant code was touched. That is often where you'll find the explanations you seek.
Re: booting from a SD card on APU2: ERR R
On Apr 22 22:27:47, les...@leslie.is wrote: > Jan Stary wrote: > > bios0: vendor coreboot version "4.0.7" date 02/28/2017 > This firmware is very old. https://pcengines.github.io/ On Apr 22 23:02:40, quand...@gmail.com wrote: > Try upgrading your bios https://pcengines.github.io/ either a 4.11.0.5 or a > 4.0.30 legacy version since you are running an old coreboot build 20170228, > USB Stick upgrade here https://www.pcengines.ch/tinycore.htm. That might > help as a first step. > > Later when OpenBSD is running fine, you could use flashrom to update bios in > single suer mode (pkg_add flashrom) I installed flashrom on the USB stick I originally installed from, and upgraded to 4.11.0.5 without problems: $ cu -rd -l /dev/cuaU0 -115200 Connected to /dev/cuaU0 (speed 115200) PC Engines apu2 coreboot build 20202903 BIOS version v4.11.0.5 2032 MB DRAM After the flash, I removed the USB stick and the APU booted from the SD card - only to panic later when the SD card "disappeared" - it was not even offered on the next boot, nor was it seen at the next USB boot to be reinstalled on. So I suspect the media: On Apr 23 06:55:16, we...@weirdnet.nl wrote: > On Wed, Apr 22, 2020 at 11:54:22PM +0200, Jan Stary wrote: > | Booting from Hard Disk... > | Using drive 0, partition 3. > | Loading > | ERR R > > These "ERR x" error codes are documented in biosboot(8)[1]. They're > brief because the biosboot program is quite space constrained. In > this particular case, "ERR R", the documentation says: > > >ERR RRead error. The BIOS returned an error indication when biosboot > > attempted to read a disk sector. This might be any media error, > > including bad sectors (common on floppy disks), and invalid > > sectors (can occur with bad geometry translations). Indeed, the SD card took three inserts on another machine to appear. I will try with another one and get back. At any rate, it runs fine from the USB stick, with the new upgraded firmware. Thanks to all. Jan
Re: MIdnight Commander won't run
Stuart, I'm working on capturing the output. I think I see why you say it needs to run in a script. Thanks for the help! Jay > On 2020-04-23, Raf Czlonka wrote: >> Would this by any chance be related to the fact that pcre has been >> removed from WANTLIB[0][1] but the package still pulls in libpcre? >> >> $ ldd /usr/local/bin/mc | grep pcre >> 1b530c236000 1b530c27c000 rlib 01 0 >> /usr/local/lib/libpcre.so.3.0 > > ldd shows indirect dependencies too, see "objdump -p /usr/local/bin/mc | > grep NEEDED" for the direct dep's. > > in this case pcre is pulled in by glib2, an excerpt from a working run with > LD_DEBUG set: > > ... > linking dep /usr/local/lib/libglib-2.0.so.4201.3 as child of > /usr/local/lib/libgmodule-2.0.so.4200.10 > examining: '/usr/local/lib/libglib-2.0.so.4201.3' > loading: libiconv.so.7.0 required by /usr/local/lib/libglib-2.0.so.4201.3 > loading: libpcre.so.3.0 required by /usr/local/lib/libglib-2.0.so.4201.3 > flags /usr/local/lib/libpcre.so.3.0 = 0x0 > obj /usr/local/lib/libpcre.so.3.0 has mc as head > ... > > if we are to have any hope of figuring out what happened, OP will need > to provide the debug output. the most common cause would be an incomplete > update.. > > >
Re: flashrom on APU2
On Apr 23 15:38:48, mcmer-open...@tor.at wrote: > just asking because you did not mention: you are running single user, > right? No, I set securelevel to -1 for the duration of this. > I documented an firmware upgrade on 2020-03-04, for an APU2: > first I tried "flashrom -p internal -w apu2.rom", then I noted > "needs boardmismatch=force", which i then used. > > That machine is still running, unbricked. > > before: > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffb7020 (7 entries) > bios0: vendor coreboot version "88a4f96" date 03/11/2016 > (I was a bit lazy there, it seems...) > > after: > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8d020 (13 entries) > bios0: vendor coreboot version "v4.11.0.4" date 02/26/2020 Same here, but newer version: PC Engines apu2 coreboot build 20202903 BIOS version v4.11.0.5 Jan
Re: flashrom on APU2
On 2020-04-23, Jan Stary wrote:
> Eventually, flashrom aborts with
>
> Manufacturer: PC Engines
> Mainboard ID: apu2
> This coreboot image (PC Engines:apu2) does not appear to
> be correct for the detected mainboard (PC Engines:PCEngines apu2).
> Aborting. You can override this with -p internal:boardmismatch=force.
>
> Is this a banal mismatch in the names
> ("PC Engines" vs "PC Engines:PCEngines")
> or is there some real concern?
See "Special notes for PC Engines APU" in pkg-readme, and the URL referred to
there.
> Can anyone please confirm they have flashed
> their APU2 like this before I brick mine?
I've done dozens of APU2 flashes using flashrom on OpenBSD with no
problems. I have not seen the "may contain one-time programmable memory"
message though, but if you didn't see the link to the docs for APU, you
might have missed the other instructions too, so check that first.
Re: MIdnight Commander won't run
On 2020-04-23, Raf Czlonka wrote: > Would this by any chance be related to the fact that pcre has been > removed from WANTLIB[0][1] but the package still pulls in libpcre? > > $ ldd /usr/local/bin/mc | grep pcre > 1b530c236000 1b530c27c000 rlib 01 0 > /usr/local/lib/libpcre.so.3.0 ldd shows indirect dependencies too, see "objdump -p /usr/local/bin/mc | grep NEEDED" for the direct dep's. in this case pcre is pulled in by glib2, an excerpt from a working run with LD_DEBUG set: ... linking dep /usr/local/lib/libglib-2.0.so.4201.3 as child of /usr/local/lib/libgmodule-2.0.so.4200.10 examining: '/usr/local/lib/libglib-2.0.so.4201.3' loading: libiconv.so.7.0 required by /usr/local/lib/libglib-2.0.so.4201.3 loading: libpcre.so.3.0 required by /usr/local/lib/libglib-2.0.so.4201.3 flags /usr/local/lib/libpcre.so.3.0 = 0x0 obj /usr/local/lib/libpcre.so.3.0 has mc as head ... if we are to have any hope of figuring out what happened, OP will need to provide the debug output. the most common cause would be an incomplete update..
Re: Using a C310 Logitech webcam mic with internal speakers
On Thu, Apr 23, 2020 at 10:01:52AM -0400, Jon Fineman wrote: > On 2020-04-23 08:40, Alexandre Ratchov wrote: > > On Wed, Apr 22, 2020 at 02:17:35PM +, Jon Fineman wrote: > > > > > > Is there a way to set the mic to one channel and the speakers to > > > another? Or merge the speakers from channel rsnd/0 and rsnd/1 > > > together and have them output on rsnd/0? > > > > Sorry, two devices can't be combined into a single one on OpenBSD. > > > > What started me down this path was that I can't get chromium or firefox to > recognize the webcam if it is using rsnd/1. Changing it to rsnd/0 allowed > the browsers to see it. > > Am I doing something wrong with configuring things? I am on 6.7 > GENERIC.MP#128 amd64. > > If the browser recognizes the webcam on rsnd/1 I could then get a combo > headphone and mic and plug that into rsnd/0, assuming the browser will > recognize the audio on rsnd/0. > The c310 has two devices inside a webcam and a usb microphone. The webcam is a video(4) device and can be used for video capture no matter if the microphone is used or not. For video(4) devices to work, /dev/video0 permissions need to be adjusted. Currently browsers need a full-duplex audio device for telephony web-sites, so the webcam microphone won't work for them, sorry. Note that the "rsnd/N" you're refering to were disabled to regular users recently, but that's not related your problem.
Re: rc daemon_timeout
On Thu, Apr 23, 2020 at 02:34:20PM +0200, Thomas de Grivel wrote:
> I tried changing the following line in /etc/rc.d/rc.subr but the
> actual timeout remains 30 sec (from 'time').
> > [ -z "${daemon_timeout}" ] && daemon_timeout=600
rm /var/run/rc.d/my_daemon
--
Antoine
Comments in source code
Hey devs and all, I'm kind of new to OpenBSD, only working on ports so far so take what I say with chill. I've been reading the source code in GIT and felt a real lack of comments explaining what the code is doing. Is this something encouraged in obsd? I would really like to have something more than super condensed one line explanations like in style(9). Just wanted to express my frustration and also to ask if there is any better way to understand how the code is working? I feel like this would deter a lot of new contributors, me including. Hopefully I don't sound too negative. I'm willing to send patches which just add comments and explanations, if there is any interest from the devs. Best, Aisha
Re: Using a C310 Logitech webcam mic with internal speakers
On 2020-04-23 08:40, Alexandre Ratchov wrote: On Wed, Apr 22, 2020 at 02:17:35PM +, Jon Fineman wrote: Is there a way to set the mic to one channel and the speakers to another? Or merge the speakers from channel rsnd/0 and rsnd/1 together and have them output on rsnd/0? Sorry, two devices can't be combined into a single one on OpenBSD. What started me down this path was that I can't get chromium or firefox to recognize the webcam if it is using rsnd/1. Changing it to rsnd/0 allowed the browsers to see it. Am I doing something wrong with configuring things? I am on 6.7 GENERIC.MP#128 amd64. If the browser recognizes the webcam on rsnd/1 I could then get a combo headphone and mic and plug that into rsnd/0, assuming the browser will recognize the audio on rsnd/0.
Re: flashrom on APU2
Hello Jan,
just asking because you did not mention: you are running single user,
right?
I documented an firmware upgrade on 2020-03-04, for an APU2:
first I tried "flashrom -p internal -w apu2.rom", then I noted
"needs boardmismatch=force", which i then used.
That machine is still running, unbricked.
before:
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffb7020 (7 entries)
bios0: vendor coreboot version "88a4f96" date 03/11/2016
(I was a bit lazy there, it seems...)
after:
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8d020 (13 entries)
bios0: vendor coreboot version "v4.11.0.4" date 02/26/2020
Marcus
h...@stare.cz (Jan Stary), 2020.04.23 (Thu) 15:02 (CEST):
> I am flashing my APU2's firmware on current/amd64,
> using the flashrom port; script and dmesg below.
> I would like to make sure about a few nits before going ahead.
>
> Probe first:
>
> # flashrom -p internal
> flashrom v1.1 on OpenBSD 6.7 (amd64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
> coreboot table found at 0x77fae000.
> Found chipset "AMD FCH".
> Enabling flash write... OK.
> Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical address
> 0xff80.
> No operations were specified.
>
> Make a backup:
>
> # flashrom -r /tmp/rom -p internal
> flashrom v1.1 on OpenBSD 6.7 (amd64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
> coreboot table found at 0x77fae000.
> Found chipset "AMD FCH".
> Enabling flash write... OK.
> Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical
> address 0xff80.
> Reading flash... done.
>
> Then write:
>
> # flashrom -V -w /home/hans/apu2_v4.11.0.5.rom -p internal
>
> After probing for various chips, flashrom finds:
>
> Found Winbond flash chip "W25Q64.V" (8192 kB, SPI).
> This chip may contain one-time programmable memory. flashrom cannot read
> and may never be able to write it, hence it may not be able to completely
> clone the contents of this chip (see man page for details).
>
> I am confused: flashrom -r has just read this memory,
> and flashrom -w is supposed to overwrite it, right?
>
> It also says
>
> coreboot last image size (not ROM size) is 8388608 bytes.
>
> Indeed, 8388608 is the size of /home/hans/apu2_v4.11.0.5.rom
> which is precisely 8192 * 1024, which is also the size of the
> backup obtained with flashrom -r. Should I be concerned about
> some mismatch, or is flashrom just emphasizing this is the
> image file size (and not stating any difference)?
>
> Eventually, flashrom aborts with
>
> Manufacturer: PC Engines
> Mainboard ID: apu2
> This coreboot image (PC Engines:apu2) does not appear to
> be correct for the detected mainboard (PC Engines:PCEngines apu2).
> Aborting. You can override this with -p internal:boardmismatch=force.
>
> Is this a banal mismatch in the names
> ("PC Engines" vs "PC Engines:PCEngines")
> or is there some real concern?
>
> Can anyone please confirm they have flashed
> their APU2 like this before I brick mine?
>
> Thank you
>
> Jan
>
>
>
> # flashrom -V -w /home/hans/apu2_v4.11.0.5.rom -p internal
>
> flashrom v1.1 on OpenBSD 6.7 (amd64)
> flashrom is free software, get the source code at https://flashrom.org
>
> flashrom was built with libpci 3.6.3, LLVM Clang 8.0.1
> (tags/RELEASE_801/final), little endian
> Command line (5 args): flashrom -V -w /home/hans/apu2_v4.11.0.5.rom -p
> internal
> Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
> Initializing internal programmer
> Found candidate at: 0500-0510
> Found coreboot table at 0x0500.
> Found candidate at: -0170
> Found coreboot table at 0x.
> coreboot table found at 0x77fae000.
> coreboot header(24) checksum: 41fb table(368) checksum: 2ad9 entries: 14
> Vendor ID: PC Engines, part ID: PCEngines apu2
> Using Internal DMI decoder.
> DMI string chassis-type: "Desktop"
> DMI string system-manufacturer: "PC Engines"
> DMI string system-product-name: "APU2"
> DMI string system-version: "1.0"
> DMI string baseboard-manufacturer: "PC Engines"
> DMI string baseboard-product-name: "APU2"
> DMI string baseboard-version: "1.0"
> Found chipset "AMD FCH" with PCI ID 1022:780e.
> Enabling flash write... SPI base address is at 0xfec1
> Yangtze detected.
> SpiRomEnable=1, RouteTpm2Sp=0, PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1
> (0x0fc82300) SpiArbEnable=1, IllegalAccess=0, SpiAccessMacRomEn=1,
> SpiHostAccessRomEn=1, ArbWaitCount=7, SpiBusy=0
> Using SPI_CS0
> GPIO11 used for SPI_DO
> GPIO12 used for SPI_DI
> GPIO31 used for SPI_HOLD
> GPIO32 used for SPI_CS
> GPIO47 used for SPI_CLK
> SpiReadMode=Normal (up to 33 MHz) (0)
> Setting read mode to "Normal (up to 66 MHz)" succeeded.
> UseSpi100 is enabled
> NormSpeedNew
Re: flashrom on APU2
On Thu, Apr 23, 2020 at 3:04 PM Jan Stary wrote:
>
> Eventually, flashrom aborts with
>
> Manufacturer: PC Engines
> Mainboard ID: apu2
> This coreboot image (PC Engines:apu2) does not appear to
> be correct for the detected mainboard (PC Engines:PCEngines apu2).
> Aborting. You can override this with -p internal:boardmismatch=force.
>
> Is this a banal mismatch in the names
> ("PC Engines" vs "PC Engines:PCEngines")
> or is there some real concern?
>
> Can anyone please confirm they have flashed
> their APU2 like this before I brick mine?
>
>
Yeah, this is a known thing. I don't remember when and where it happened,
but it happened to my APU as well.
It's safe to override.
--
chs
flashrom on APU2
I am flashing my APU2's firmware on current/amd64,
using the flashrom port; script and dmesg below.
I would like to make sure about a few nits before going ahead.
Probe first:
# flashrom -p internal
flashrom v1.1 on OpenBSD 6.7 (amd64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
coreboot table found at 0x77fae000.
Found chipset "AMD FCH".
Enabling flash write... OK.
Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical address
0xff80.
No operations were specified.
Make a backup:
# flashrom -r /tmp/rom -p internal
flashrom v1.1 on OpenBSD 6.7 (amd64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
coreboot table found at 0x77fae000.
Found chipset "AMD FCH".
Enabling flash write... OK.
Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical
address 0xff80.
Reading flash... done.
Then write:
# flashrom -V -w /home/hans/apu2_v4.11.0.5.rom -p internal
After probing for various chips, flashrom finds:
Found Winbond flash chip "W25Q64.V" (8192 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
I am confused: flashrom -r has just read this memory,
and flashrom -w is supposed to overwrite it, right?
It also says
coreboot last image size (not ROM size) is 8388608 bytes.
Indeed, 8388608 is the size of /home/hans/apu2_v4.11.0.5.rom
which is precisely 8192 * 1024, which is also the size of the
backup obtained with flashrom -r. Should I be concerned about
some mismatch, or is flashrom just emphasizing this is the
image file size (and not stating any difference)?
Eventually, flashrom aborts with
Manufacturer: PC Engines
Mainboard ID: apu2
This coreboot image (PC Engines:apu2) does not appear to
be correct for the detected mainboard (PC Engines:PCEngines apu2).
Aborting. You can override this with -p internal:boardmismatch=force.
Is this a banal mismatch in the names
("PC Engines" vs "PC Engines:PCEngines")
or is there some real concern?
Can anyone please confirm they have flashed
their APU2 like this before I brick mine?
Thank you
Jan
# flashrom -V -w /home/hans/apu2_v4.11.0.5.rom -p internal
flashrom v1.1 on OpenBSD 6.7 (amd64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.6.3, LLVM Clang 8.0.1
(tags/RELEASE_801/final), little endian
Command line (5 args): flashrom -V -w /home/hans/apu2_v4.11.0.5.rom -p internal
Using clock_gettime for delay loops (clk_id: 3, resolution: 1ns).
Initializing internal programmer
Found candidate at: 0500-0510
Found coreboot table at 0x0500.
Found candidate at: -0170
Found coreboot table at 0x.
coreboot table found at 0x77fae000.
coreboot header(24) checksum: 41fb table(368) checksum: 2ad9 entries: 14
Vendor ID: PC Engines, part ID: PCEngines apu2
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: "PC Engines"
DMI string system-product-name: "APU2"
DMI string system-version: "1.0"
DMI string baseboard-manufacturer: "PC Engines"
DMI string baseboard-product-name: "APU2"
DMI string baseboard-version: "1.0"
Found chipset "AMD FCH" with PCI ID 1022:780e.
Enabling flash write... SPI base address is at 0xfec1
Yangtze detected.
SpiRomEnable=1, RouteTpm2Sp=0, PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1
(0x0fc82300) SpiArbEnable=1, IllegalAccess=0, SpiAccessMacRomEn=1,
SpiHostAccessRomEn=1, ArbWaitCount=7, SpiBusy=0
Using SPI_CS0
GPIO11 used for SPI_DO
GPIO12 used for SPI_DI
GPIO31 used for SPI_HOLD
GPIO32 used for SPI_CS
GPIO47 used for SPI_CLK
SpiReadMode=Normal (up to 33 MHz) (0)
Setting read mode to "Normal (up to 66 MHz)" succeeded.
UseSpi100 is enabled
NormSpeedNew is 33 MHz
FastSpeedNew is 33 MHz
AltSpeedNew is 16.5 MHz
TpmSpeedNew is 16.5 MHz
Setting SPI clock to 16.5 MHz (0x3).
IMC is not active.
ROM strap override is not active
OK.
The following protocols are supported: LPC, FWH, SPI.
Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L10PU, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L40PT, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
Probing for AMIC A25L80P, 1024 kB:
Re: Using a C310 Logitech webcam mic with internal speakers
On Wed, Apr 22, 2020 at 02:17:35PM +, Jon Fineman wrote: > > Is there a way to set the mic to one channel and the speakers to > another? Or merge the speakers from channel rsnd/0 and rsnd/1 > together and have them output on rsnd/0? Sorry, two devices can't be combined into a single one on OpenBSD.
Re: rc daemon_timeout
I tried changing the following line in /etc/rc.d/rc.subr but the
actual timeout remains 30 sec (from 'time').
> [ -z "${daemon_timeout}" ] && daemon_timeout=600
Le jeu. 23 avr. 2020 à 14:28, Thomas de Grivel a écrit :
>
> Le jeu. 23 avr. 2020 à 13:57, Antoine Jacoutot a
> écrit :
> >
> > On Thu, Apr 23, 2020 at 12:18:40PM +0100, Raf Czlonka wrote:
> > > On Thu, Apr 23, 2020 at 12:00:59PM BST, Thomas de Grivel wrote:
> > > > Hello,
> > > >
> > > > I have some trouble starting up a daemon on OpenBSD 6.6 stable using rc
> > > > :
> > > >
> > > > in /etc/rc.d/my_daemon :
> > > >
> > > > > #!/bin/ksh
> > > > >
> > > > > daemon="/home/my-user/start"
> > > > > daemon_user=my-user
> > > > > daemon_timeout=600
> > > > >
> > > > > . /etc/rc.d/rc.subr
> > > > >
> > > > > echo "daemon_timeout ${daemon_timeout}"
> > > > > rc_cmd $1
> > > >
> > > > Then I run the following command :
> > > >
> > > > > # time /etc/rc.d/my_daemon
> > > > > daemon_timeout 600
> > > > > seuldanslenoir_staging(timeout)
> > > > > 0m30.54s real 0m00.04s user 0m00.05s system
> > > >
> > > > So the actual timeout is still 30 seconds which is the default in
> > > > /etc/rc.d/rc.subr
> > > >
> > > > What did I do wrong ?
> > >
> > > Order - move the source ('.) line to the top.
> >
> > Hmm no, don't do that.
> >
> > What is the output of 'rcctl get my_daemon timeout'
>
> I did not change anything.
>
> 'rcctl get my_daemon timout' returns 600 as expected.
>
>
> --
> Thomas de Grivel
> kmx.io
--
Thomas de Grivel
kmx.io
Re: rc daemon_timeout
Le jeu. 23 avr. 2020 à 13:57, Antoine Jacoutot a écrit :
>
> On Thu, Apr 23, 2020 at 12:18:40PM +0100, Raf Czlonka wrote:
> > On Thu, Apr 23, 2020 at 12:00:59PM BST, Thomas de Grivel wrote:
> > > Hello,
> > >
> > > I have some trouble starting up a daemon on OpenBSD 6.6 stable using rc :
> > >
> > > in /etc/rc.d/my_daemon :
> > >
> > > > #!/bin/ksh
> > > >
> > > > daemon="/home/my-user/start"
> > > > daemon_user=my-user
> > > > daemon_timeout=600
> > > >
> > > > . /etc/rc.d/rc.subr
> > > >
> > > > echo "daemon_timeout ${daemon_timeout}"
> > > > rc_cmd $1
> > >
> > > Then I run the following command :
> > >
> > > > # time /etc/rc.d/my_daemon
> > > > daemon_timeout 600
> > > > seuldanslenoir_staging(timeout)
> > > > 0m30.54s real 0m00.04s user 0m00.05s system
> > >
> > > So the actual timeout is still 30 seconds which is the default in
> > > /etc/rc.d/rc.subr
> > >
> > > What did I do wrong ?
> >
> > Order - move the source ('.) line to the top.
>
> Hmm no, don't do that.
>
> What is the output of 'rcctl get my_daemon timeout'
I did not change anything.
'rcctl get my_daemon timout' returns 600 as expected.
--
Thomas de Grivel
kmx.io
Re: unveil confusion
On Thu, Apr 23, 2020 at 11:20:45AM +0200, Hiltjo Posthuma wrote:
> > beta$ ps ax | grep unveiltest
> > 40907 pg S+U 0:00.01 ./unveiltest
> > 40013 ph R+/2 0:00.00 grep unveiltest
> Hi,
>
> Below the quoted part it says in the man page:
>
> "After establishing a collection of path and permissions rules, future
> calls to unveil() can be disabled by passing two NULL arguments.
> Alternatively, pledge(2) may be used to remove the "unveil" promise."
>
> So you could use the code:
>
> if (unveil("/", "") == -1)
> err(1, "unveil");
> if (unveil(NULL, NULL) == -1)
> err(1, "unveil");
>
> For example see netcat, vmstat.
>
> By the way, maybe it's intentional but perror does not exit the program. The
> often used pattern is to use:
>
> err(1, "unveil");
>
> --
> Kind regards,
> Hiltjo
>
Oh I see so passing a blank ("") unveil creates that! Ok! Thank you!
I have another problem I was hoping you'd be able to shed light on. I'm
not sure if it's a bug or not. I have extended the program a little, here
it is:
-->
#include
#include
#include
#include
#include
#include
#define SETPROCTITLE1
#define CHROOT 1
#define SETGROUPS 1
#define WITH_PLEDGE 1
#define WITH_PARENTPLEDGE 1
void func(void);
int
main(void)
{
pid_t pid;
gid_t group;
pid = fork();
switch (pid) {
case -1:
err(1, "fork");
case 0:
#if SETPROCTITLE
setproctitle("peter was here");
#endif
#if CHROOT
if (chroot("/tmp") == -1)
err(1, "chroot");
if (chdir("/") == -1)
err(1, "chdir");
#endif
#if SETGROUPS
group = 1000;
if (setgroups(1, ) == -1) {
err(1, "setgroups");
}
if (setresgid(1000, 1000, 1000) == -1)
err(1, "setresgid");
if (setresuid(1000, 1000, 1000) == -1)
err(1, "setresuid");
#endif
if (unveil("/", "") == -1)
err(1, "unveil");
if (unveil(NULL, NULL) == -1)
err(1, "unveil");
#if WITH_PLEDGE
if (pledge("stdio", NULL) == -1)
err(1, "pledge");
#endif
func();
exit(1);
default:
break;
}
#if WITH_PARENTPLEDGE
if (pledge("stdio id proc cpath rpath unveil", NULL) == -1) {
err(1, "pledge");
}
#endif
for (;;)
sleep(1);
}
void
func()
{
int fd;
for (;;) {
#if 0
if ((fd = open("/etc/motd", O_RDONLY, 0)) < 0)
perror("open");
else
close(fd);
#endif
sleep(1);
}
}
<--
Watch what happens when you set WITH_PLEDGE to 0 and back to 1 in a ps.
It loses the U flag in a ps ax. I've been chasing this condition for a
while now I think it's a kernel bug. Can you concur or is my system odd?
WITH_PLEDGE set to 1:
beta$ ps ax | grep unveiltest
24089 p7 S+p 0:00.01 ./unveiltest
63901 p7 S+p 0:00.01 unveiltest: peter was here (unveiltest)
WITH_PLEDGE set to 0:
beta$ ps ax | grep unveiltest
87932 p7 S+p 0:00.19 ./unveiltest
74818 p7 S+U 0:00.00 unveiltest: peter was here (unveiltest)
I'm basically copying out the functions of a program of mine here in an
effort to see a U flag on the processes.
Best regards,
-peter
Re: rc daemon_timeout
On Thu, Apr 23, 2020 at 12:18:40PM +0100, Raf Czlonka wrote:
> On Thu, Apr 23, 2020 at 12:00:59PM BST, Thomas de Grivel wrote:
> > Hello,
> >
> > I have some trouble starting up a daemon on OpenBSD 6.6 stable using rc :
> >
> > in /etc/rc.d/my_daemon :
> >
> > > #!/bin/ksh
> > >
> > > daemon="/home/my-user/start"
> > > daemon_user=my-user
> > > daemon_timeout=600
> > >
> > > . /etc/rc.d/rc.subr
> > >
> > > echo "daemon_timeout ${daemon_timeout}"
> > > rc_cmd $1
> >
> > Then I run the following command :
> >
> > > # time /etc/rc.d/my_daemon
> > > daemon_timeout 600
> > > seuldanslenoir_staging(timeout)
> > > 0m30.54s real 0m00.04s user 0m00.05s system
> >
> > So the actual timeout is still 30 seconds which is the default in
> > /etc/rc.d/rc.subr
> >
> > What did I do wrong ?
>
> Order - move the source ('.) line to the top.
Hmm no, don't do that.
What is the output of 'rcctl get my_daemon timeout'
--
Antoine
Re: Useful cwm patch [was: When will be created a great desktop experience for OpenBSD?]
In article <20200415193758.csp3wtf4hnhdc...@gmx.com> Dumitru Moldovan wrote: > On Tue, Oct 29, 2019 at 10:43:26AM +0100, Walter Alejandro Iglesias wrote: > >This second one is still pending (no response from the maintainer so > >far): > > > > https://marc.info/?l=openbsd-tech=155931484124288=2 > > Apologies for resurrecting a dead and buried thread, but this second > patch is actually really useful. Have tested it for a few months as a > single patch to my 6.6 cwm, it works so good I actually forgot about it. > > CC'ing cwm maintainer in the hope he'll consider it. Thanks! > > Let me add that *this is a bug*, not a feature. A bug that affects basic functionality. Walter
Re: rc daemon_timeout
On Thu, Apr 23, 2020 at 12:00:59PM BST, Thomas de Grivel wrote:
> Hello,
>
> I have some trouble starting up a daemon on OpenBSD 6.6 stable using rc :
>
> in /etc/rc.d/my_daemon :
>
> > #!/bin/ksh
> >
> > daemon="/home/my-user/start"
> > daemon_user=my-user
> > daemon_timeout=600
> >
> > . /etc/rc.d/rc.subr
> >
> > echo "daemon_timeout ${daemon_timeout}"
> > rc_cmd $1
>
> Then I run the following command :
>
> > # time /etc/rc.d/my_daemon
> > daemon_timeout 600
> > seuldanslenoir_staging(timeout)
> > 0m30.54s real 0m00.04s user 0m00.05s system
>
> So the actual timeout is still 30 seconds which is the default in
> /etc/rc.d/rc.subr
>
> What did I do wrong ?
Order - move the source ('.) line to the top.
R.
> Is this a known issue ? I could not find an
> evident answer to this problem looking at /etc/rc.d/rc.subr
>
> --
> Thomas de Grivel
> kmx.io
>
rc daemon_timeout
Hello,
I have some trouble starting up a daemon on OpenBSD 6.6 stable using rc :
in /etc/rc.d/my_daemon :
> #!/bin/ksh
>
> daemon="/home/my-user/start"
> daemon_user=my-user
> daemon_timeout=600
>
> . /etc/rc.d/rc.subr
>
> echo "daemon_timeout ${daemon_timeout}"
> rc_cmd $1
Then I run the following command :
> # time /etc/rc.d/my_daemon
> daemon_timeout 600
> seuldanslenoir_staging(timeout)
> 0m30.54s real 0m00.04s user 0m00.05s system
So the actual timeout is still 30 seconds which is the default in
/etc/rc.d/rc.subr
What did I do wrong ? Is this a known issue ? I could not find an
evident answer to this problem looking at /etc/rc.d/rc.subr
--
Thomas de Grivel
kmx.io
Re: unveil confusion
On Thu, Apr 23, 2020 at 09:33:51AM +0200, Peter J. Philipp wrote:
> Hi,
>
> From the unveil manpage:
>
> The first call to unveil() removes visibility of the entire filesystem
> from all other filesystem-related system calls (such as open(2), chmod(2)
> and rename(2)), except for the specified path and permissions.
>
> Can the first call also be the last? I have a test program called
> unveiltest.c
> and it does the following:
>
> paste>
> #include
> #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> int fd;
>
> #ifdef UNVEIL_MOTD
> if (unveil("/etc/motd", "r") < 0)
> perror("unveil");
> #endif
> if (unveil(NULL, NULL) < 0)
> perror("unveil");
>
> for (;;) {
> if ((fd = open("/etc/motd", O_RDONLY, 0)) < 0)
> perror("open");
> else
> close(fd);
>
> sleep(1);
> }
> }
> <--
>
> When I run it without UNVEIL_MOTD, meaning my first (and last) unveil was
> NULL, NULL.. it doesn't deny /etc/motd reads.
>
> beta$ cc -g -o unveiltest unveiltest.c
> beta$ ./unveiltest
> ^C
>
> beta$ ps ax | grep unveiltest
> 21482 pg S+ 0:00.10 ./unveiltest
> 98206 ph R+/3 0:00.00 grep unveiltest
>
> And when I recompile with UNVEIL_MOTD same behaviour:
>
> beta$ cc -g -DUNVEIL_MOTD -o unveiltest unveiltest.c
> beta$ ./unveiltest
> ^C
>
> except there is a difference in the ps listing:
>
> beta$ ps ax | grep unveiltest
> 40907 pg S+U 0:00.01 ./unveiltest
> 40013 ph R+/2 0:00.00 grep unveiltest
>
> Am I interpreting unveil manpage wrong or is it written wrong? I did have
> a first call to unveil in the first example only it's NULL, NULL, me telling
> the system I don't want anything opened at all. Is there any way to do that?
>
> Or is that pledge()'s job?
>
> Another weird one I have is that I call unveil() to a path but chroot() later,
> then call unveil(NULL, NULL) and the ps flag doesn't indicate the U flag. Is
> because of the chroot() the unveil lost?
>
> Best regards,
> -peter
>
Hi,
Below the quoted part it says in the man page:
"After establishing a collection of path and permissions rules, future
calls to unveil() can be disabled by passing two NULL arguments.
Alternatively, pledge(2) may be used to remove the "unveil" promise."
So you could use the code:
if (unveil("/", "") == -1)
err(1, "unveil");
if (unveil(NULL, NULL) == -1)
err(1, "unveil");
For example see netcat, vmstat.
By the way, maybe it's intentional but perror does not exit the program. The
often used pattern is to use:
err(1, "unveil");
--
Kind regards,
Hiltjo
Re: OT: Qualcomm MDM
On 2020-04-22, tru...@tutanota.com wrote: > hello list, > > digging the net [1] reveales MSM standing for "Mobile system/soc Modem" > and MDM standing for "Mobile Data Modem". > > "Qualcomm MSM" is being explicitly mentined at ucom(4) and usb(4), no > mention of "Qualcomm MDM" neither at manuals nor at OpenBSD lists' > archives thou. > > the question is is > https://www.alcatelmobile.com/product/mobile-broadband/mobile-wifi/linkkey-lte-cat4-usb-dongle/ > supported while umsm(4) does not list it? > > should i buy or should i cry - someone knowledgeable take time to advise > please? > (please copy me, thank you!) > /tru > > [1] > https://www.quora.com/What-is-the-difference-between-Qualcomm-Board-and-Model?share=1 > Is somebody selling those yet? The device in your link is Linkkey IK41 which is new so you probably won't find anyone who tried them with OpenBSD yet, if they are even available (release was meant to be Q1 2020 but it wouldn't surprise me if it has been caught up in shipping delays from PRC). I would guess it maybe a umb(4) device but I think you would need to buy one to find out (so if you do, get it from somewhere that will accept returns if necessary). Most places selling "alcatel linkkey" seem to have the older model IK40 which has the word "alcatel" not just the logo (and does not have the external antenna connectors). That one is from around 2016, not sure what driver it will use, I would guess umsm or urndis is more likely for IK40 but it may require some mode-switch command that we don't have yet.
Re: MIdnight Commander won't run
On Thu, Apr 23, 2020 at 04:42:34AM BST, Aaron Mason wrote: > On Wed, Apr 22, 2020 at 11:17 AM Jay Hart wrote: > > > > Upgraded my router from 6.5 to 6.6. Followed the upgrade guide and > > installed most, not all, of > > the file sets. I did not install the games set or several of the X sets. > > > > I ran pkg_add -u and also used sysclean to find and remove all unneeded > > files. > > > > Afterwards, trying to run 'mc' results in: > > > > tangerine# mc > > ld.so can't load library libpcre.so.3.0 > > Killed > > > > libpcre.so.3.0 is in /usr/local/lib > > > > Not sure how to go about fixing this, google searches did not turn up > > anything on this. > > > > Looking for a bit of help. > > > > Thanks, > > > > Jay > > > > I find it rare that an upgrade ever goes smoothly for any OS. Have > you tried running ldconfig(8)? > This is part of rc(8) so, like sthen@ already mentioned, this isn't necessary. Would this by any chance be related to the fact that pcre has been removed from WANTLIB[0][1] but the package still pulls in libpcre? $ ldd /usr/local/bin/mc | grep pcre 1b530c236000 1b530c27c000 rlib 01 0 /usr/local/lib/libpcre.so.3.0 [0] https://cvsweb.openbsd.org/ports/misc/mc/Makefile?only_with_tag=OPENBSD_6_6 [1] https://cvsweb.openbsd.org/ports/misc/mc/Makefile.diff?r1=1.67=1.68=h P.S. From personal experience, OpenBSD upgrades are as smooth as they come. P.P.S. sysclean(8) works great so shout-out to semarie@ o/ :^) Regards, Raf
Re: MIdnight Commander won't run
On 2020-04-23, Aaron Mason wrote: > On Wed, Apr 22, 2020 at 11:17 AM Jay Hart wrote: >> >> Upgraded my router from 6.5 to 6.6. Followed the upgrade guide and >> installed most, not all, of >> the file sets. I did not install the games set or several of the X sets. >> >> I ran pkg_add -u and also used sysclean to find and remove all unneeded >> files. >> >> Afterwards, trying to run 'mc' results in: >> >> tangerine# mc >> ld.so can't load library libpcre.so.3.0 >> Killed >> >> libpcre.so.3.0 is in /usr/local/lib >> >> Not sure how to go about fixing this, google searches did not turn up >> anything on this. >> >> Looking for a bit of help. >> >> Thanks, >> >> Jay >> > > I find it rare that an upgrade ever goes smoothly for any OS. Have > you tried running ldconfig(8)? It shouldn't be necessary to run that manually.
unveil confusion
Hi,
>From the unveil manpage:
The first call to unveil() removes visibility of the entire filesystem
from all other filesystem-related system calls (such as open(2), chmod(2)
and rename(2)), except for the specified path and permissions.
Can the first call also be the last? I have a test program called unveiltest.c
and it does the following:
paste>
#include
#include
#include
#include
#include
int
main(void)
{
int fd;
#ifdef UNVEIL_MOTD
if (unveil("/etc/motd", "r") < 0)
perror("unveil");
#endif
if (unveil(NULL, NULL) < 0)
perror("unveil");
for (;;) {
if ((fd = open("/etc/motd", O_RDONLY, 0)) < 0)
perror("open");
else
close(fd);
sleep(1);
}
}
<--
When I run it without UNVEIL_MOTD, meaning my first (and last) unveil was
NULL, NULL.. it doesn't deny /etc/motd reads.
beta$ cc -g -o unveiltest unveiltest.c
beta$ ./unveiltest
^C
beta$ ps ax | grep unveiltest
21482 pg S+ 0:00.10 ./unveiltest
98206 ph R+/3 0:00.00 grep unveiltest
And when I recompile with UNVEIL_MOTD same behaviour:
beta$ cc -g -DUNVEIL_MOTD -o unveiltest unveiltest.c
beta$ ./unveiltest
^C
except there is a difference in the ps listing:
beta$ ps ax | grep unveiltest
40907 pg S+U 0:00.01 ./unveiltest
40013 ph R+/2 0:00.00 grep unveiltest
Am I interpreting unveil manpage wrong or is it written wrong? I did have
a first call to unveil in the first example only it's NULL, NULL, me telling
the system I don't want anything opened at all. Is there any way to do that?
Or is that pledge()'s job?
Another weird one I have is that I call unveil() to a path but chroot() later,
then call unveil(NULL, NULL) and the ps flag doesn't indicate the U flag. Is
because of the chroot() the unveil lost?
Best regards,
-peter
Re: WLAN throughput less 10Mb/s
On Thu, Apr 23, 2020 at 02:52:09AM -0300, Anatoli wrote: > How do the same drivers work in Linux? Can't "we" "just" "copy" the code > from there? That's already what we are doing. But porting (what you call "just copying") code is a lot of work, too. This stuff needs a lot of attention to detail to work right and there is already too much divergance between any of these kernels for cp -R to produce a useful result. And apart from a working wifi device you would like the code that runs on your CPU to be audited as well, no? > Or does the GPL licensing absolutely prevents from analyzing > Linux code and using their implementation details? Linux has some BSD-licensed drivers and we are already porting them. A lot of iwm(4), iwx(4), and bwfm(4) code came from Linux. There's a plan to port ath10k code from Linux but that project is stuck due to lack of time because there is too much to do. This problem isn't specific to OpenBSD either. I am getting regular email from people trying to port iwx(4) from OpenBSD to FreeBSD, and not being able to get it to work even though the driver works on OpenBSD.
Re: WLAN throughput less 10Mb/s
How do the same drivers work in Linux? Can't "we" "just" "copy" the code from there? Or does the GPL licensing absolutely prevents from analyzing Linux code and using their implementation details? Two years ago FreeBSD started implementing AC stack [1]. Maybe there could be a collaborative project among the BSDs to get wifi working on the same (or better) level as in Linux? FreeBSD Foundation announced a month ago they are starting to sponsor work on full AC support [2]. Why not to seize the opportunity and unify the wifi stacks so that the drivers are more or less same code between the 2 BSDs? Then any improvement to the stack and any driver would be useful for both projects. Otherwise it looks like it's too much work to be done by one-two devs on occasional basis. The FreeBSD AC todo list [3] (which is still incomplete) looks overwhelming. Anyway, thanks a lot for what is already done! [1] https://adrianchadd.blogspot.com/2017/04/bringing-up-80211ac-on-freebsd.html [2] https://www.phoronix.com/scan.php?page=news_item=802.11ac-FreeBSD-Sponsor [3] https://wiki.freebsd.org/WiFi/80211ac On 14/4/20 08:01, Stefan Sperling wrote: > On Tue, Apr 14, 2020 at 11:37:24AM +0100, Kevin Chadwick wrote: >> On 2020-04-14 09:21, Stefan Sperling wrote: >>> Regarding other chipsets, if you want the fastest possible AP on OpenBSD >>> your best option right now is to get a bwfm(4) device, which offloads almost >>> all of its 802.11 operation into a firmware blob running in the embedded >>> system on the device. >> >> Interesting. >> >> BWFM(4) >> CAVEATS >> The firmware is outdated and contains known vulnerabilities. >> >> Any more information on the seriousness of these vulnerabilities? >> >> I can probably look it up in CVS actually but figured it *may* be prudent of >> me >> to highlight that caveat on the list explicitly, in any case. > > I honestly don't know and don't really care. Even if we knew what publicly > known or unknown bugs linger in there, we couldn't do anything about it. > All we can really do is upgrade the firmware and hope for the best. > > The same is true for the Intel wifi chips. > > What's nice about athn(4) is that the full software stack from driver to > hardware is open source, including firmware for USB devices. So it's > possible to fix issues, though it can be quite hard to fix known bugs. > No firmware abstraction means the driver needs to deal with a lot of > complexity all by itself, i.e. problems that engineers at vendors with > proper testing equipment and low-level expertise tend to deal with. >
