kshcolor - a script for decorating ksh shell programs and terminals
Hiya folks,
As a learning project to teach myself how to use the ksh shell I wrote a
helper script to set ansi colors and decorations that I'm calling
*kshcolor*.
The script is available here for anyone who is intrigued:
https://github.com/tbullock/kshcolor
The project includes a makefile to build the script, this was necessary
since manually typing ANSI escape sequences is annoying so I chose to
generate those rather than fail at typing them.
To install run `make install`
To run the included test run `make test`
The makefile will install the file kshcolor.sh in $(HOME)/bin
The script includes the following functions:
bk # Sets Black
rd # Sets Red
gr # Sets Green
ye # Sets Yellow
bl # Sets Blue
mg # Sets Magenta
cy # Sets Cyan
wh # Sets White
bg_bk # Sets background Black
bg_rd # Sets background Red
bg_gr # Sets background Green
bg_ye # Sets background Yellow
bg_bl # Sets background Blue
bg_mg # Sets background Magenta
bg_cy # Sets background Cyan
bg_wh # Sets background White
bold# Bold
dim # Dim
underline # Underline
blink # Blink (this may not be implemented by your terminal)
invert # Invert
hidden # Hidden
reset_decorations # clear inherited decorations
These functions do not directly make any visible changes to the
terminal, rather that is left to the function:
decorate# applies configured decorations to the first argument
The decorate function looks at the currently configured decorations
(colours and attributes) and applies the necessary ANSI escape sequences
to tell the terminal how it's argument is to be rendered. If the
terminal doesn't support at least the standard 8 ANSI colours this
become a no-op and leaves the variable undecorated.
The result can then be sent to echo or print or wherever your heart
desires them to go (maybe Narnia!?).
Example:
# Apply foreground and background colours separately
rd
bg_ye
text1=$(decorate "this text is red ")
# Change the background colour
bg_mg
text2=$(decorate "but the background changes")
# Display the decorated text
echo "${text1}${text2}"
reset_decorations
This project was largely an educational evening for me in how ksh
scripting works, if people find it useful, cute or want to use it to
splash the rainbow all over their terminal, then please let me know what
you come up with.
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 3:53 a.m., Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: >> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: >>> >>> On 2022-01-10 2:18 a.m., Jonathan Gray wrote: >>>> On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: >>>>> The manpage incorrectly describes the behaviour and usage of >>>>> pci_mapreg_probe(9). This function does not return 0 for success and !0 >>>>> for failure as described in the manual, see the diff below for a >>>>> possible re-wording and corrected description. >>>> >>>> I agree the return value is wrong but your description introduces an >>>> error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. >>>> Which is something that the pci_mapreg_type text also gets wrong. >>>> >>>> How about this to start with? >>> >>> It certainly corrects the mechanical issue with the returns, it doesn't help >>> though with understanding how to use the function correctly though. Under >>> what circumstances will the type bits get set as you indicate? I wasn't at >>> all clear about that from peering through the call tree. >> >> as the define would suggest, when it is a 64-bit mem bar > > expanding on this some more Here is what I have written so far. I added what I found to be necessary to actually use the API not having used it in OpenBSD before. More experienced devs might just *know* this but as someone who had to try and understand what it was doing using just the manual and the source code this is what was missing for me. Index: share/man/man9/pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 -0000 1.1 +++ share/man/man9/pci_mapreg_map.9 11 Jan 2022 04:12:32 - @@ -1,6 +1,7 @@ .\"$OpenBSD: pci_mapreg_map.9,v 1.1 2019/02/23 04:54:25 dlg Exp $ .\" .\" Copyright (c) 2019 David Gwynne +.\" Copyright (c) 2022 Ted Bullock .\" All rights reserved. .\" .\" Permission to use, copy, modify, and distribute this software for any @@ -15,7 +16,7 @@ .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" -.Dd $Mdocdate: February 23 2019 $ +.Dd $Mdocdate: January 10 2022 $ .Dt PCI_MAPREG_MAP 9 .Os .Sh NAME @@ -50,19 +51,21 @@ .Fa "bus_size_t *sizep" .Fa "int *flagsp" .Fc -.Ft int -.Fo pci_mapreg_probe +.Ft pcireg_t +.Fo pci_mapreg_type .Fa "pci_chipset_tag_t pc" .Fa "pcitag_t tag" .Fa "int reg" -.Fa "pcireg_t *typep" .Fc -.Ft pcireg_t -.Fo pci_mapreg_type +.Ft int +.Fo pci_mapreg_probe .Fa "pci_chipset_tag_t pc" .Fa "pcitag_t tag" .Fa "int reg" +.Fa "pcireg_t *typep" .Fc +.Fd #define PCI_MAPREG_TYPE(type) +.Fd #define PCI_MAPREG_MEM_TYPE(type) .\" .Ft int .\" .Fo pci_mem_find .\" .Fa "pci_chipset_tag_t pc" @@ -85,7 +88,43 @@ These functions provide wrappers and helpers around .Xr bus_space 9 mappings for device registers described by the Base Address Registers -(BARs) in a PCI devices configuration space. +(BARs) in a PCI devices configuration space. There are 6 BARs located in the +pci address space at 0x10, 0x14, 0x18, 0x1C, 0x20 and 0x24. The addresses +stored in the PCI BARS are used to map IO and Memory Mapped device registers. +.Pp +BARS have a complex bitmap described a follows: +.TS +center,allbox; +cb s s +cb cb cb +cb s s +c r l +c r l +cb s s +c r l +^ r l +^ r l +c r l +^ r l +c r l +cb s s +c r l. +PCI BAR Bitmap +Bits Description Values +All PCI BARs +0 Type0 Memory +\^ \^ 1 I/O +Memory BARs +1-2Location00 Any 32-bit +\^ \^ 10 < 1MB +\^ \^ 11 Any 64-bit +3 Prefetchable0 No +\^ \^ 1 Yes +4-31 Base Address16-byte aligned +I/O BARs +1 Reserved\_ +2-31 Base Address4-byte aligned +.TE .Pp .Nm pci_mapreg_map wraps a call to @@ -124,29 +163,70 @@ and .Fa flagsp pointers. .Pp +.Nm pci_mapreg_type +returns the type of register access for the registers at the BAR +referenced by +.Fa reg . +.Pp .Nm pci_mapreg_probe attempts to determine if the BAR referenced by .Fa reg -describes a valid register mapping. +describes a valid register mapping. If it does, the register type will be +updated via the pointer +.Fa typep +matching those described for the return value of +.Nm pci_mapreg_type . +If the mapping is invalid the register type should not be used. +.Fa
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 3:53 a.m., Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: >> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: >>> >>> On 2022-01-10 2:18 a.m., Jonathan Gray wrote: >>>> On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: >>>>> The manpage incorrectly describes the behaviour and usage of >>>>> pci_mapreg_probe(9). This function does not return 0 for success and !0 >>>>> for failure as described in the manual, see the diff below for a >>>>> possible re-wording and corrected description. >>>> >>>> I agree the return value is wrong but your description introduces an >>>> error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. >>>> Which is something that the pci_mapreg_type text also gets wrong. >>>> >>>> How about this to start with? >>> >>> It certainly corrects the mechanical issue with the returns, it doesn't help >>> though with understanding how to use the function correctly though. Under >>> what circumstances will the type bits get set as you indicate? I wasn't at >>> all clear about that from peering through the call tree. >> >> as the define would suggest, when it is a 64-bit mem bar Ok, then still missing from the document is the semantic distinctions between the return types and the correct usage for those types with pci_mapreg_info and pci_mapreg_map. There is also the undocumented PCI_MAPREG_TYPE and PCI_MAPREG_MEM_TYPE macros too: This usage should be incorrect? if (type == PCI_MAPREG_TYPE_MEM) I think correct form should be then if (PCI_MAPREG_TYPE(type) == PCI_MAPREG_TYPE_MEM) switch (PCI_MAPREG_MEM_TYPE(type)) PCI_MAPREG_MEM_TYPE_32BIT_1M: PCI_MAPREG_MEM_TYPE_32BIT: pci_mapreg_map for 32 bit bar PCI_MAPREG_MEM_TYPE_64BIT: pci_mapreg_map for 64 bit bar This pci stack doesn't also seem to handle pci devices with a 16 bit bar, but I also don't know if such devices actually exist so maybe this doesn't matter > expanding on this some more > > Index: pci_mapreg_map.9 > === > RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v > retrieving revision 1.1 > diff -u -p -r1.1 pci_mapreg_map.9 > --- pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1 > +++ pci_mapreg_map.9 10 Jan 2022 10:51:36 - > @@ -128,6 +128,11 @@ pointers. > attempts to determine if the BAR referenced by > .Fa reg > describes a valid register mapping. > +If it does > +.Fa typep > +will point to a value with flags matching those described for the return > value > +of > +.Nm pci_mapreg_type . > .Pp > .Nm pci_mapreg_type > returns the type of register access for the registers at the BAR > @@ -135,18 +140,22 @@ referenced by > .Fa reg . > .Sh RETURN VALUES > .Nm pci_mapreg_map , > -.Nm pci_mapreg_info , > and > -.Nm pci_mapreg_probe > +.Nm pci_mapreg_info > return 0 on success, or an > .Xr errno 2 > style value on failure. > .Pp > +.Nm pci_mapreg_probe > +returns 1 if if the BAR describes a valid mapping, 0 if not. > +.Pp > .Nm pci_mapreg_type > -returns either > -.Dv PCI_MAPREG_TYPE_IO > -or > -.Dv PCI_MAPREG_TYPE_MEM . > +returns a value with flags for type information. > +.Dv PCI_MAPREG_TYPE_IO , > +.Dv PCI_MAPREG_TYPE_MEM , > +.Dv PCI_MAPREG_MEM_TYPE_32BIT , > +.Dv PCI_MAPREG_MEM_TYPE_32BIT_1M and > +.Dv PCI_MAPREG_MEM_TYPE_64BIT . > .Sh SEE ALSO > .Xr pci 4 , > .Xr bus_space 9 , -- Ted Bullock
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 2:18 a.m., Jonathan Gray wrote: On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: The manpage incorrectly describes the behaviour and usage of pci_mapreg_probe(9). This function does not return 0 for success and !0 for failure as described in the manual, see the diff below for a possible re-wording and corrected description. I agree the return value is wrong but your description introduces an error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. Which is something that the pci_mapreg_type text also gets wrong. How about this to start with? It certainly corrects the mechanical issue with the returns, it doesn't help though with understanding how to use the function correctly though. Under what circumstances will the type bits get set as you indicate? I wasn't at all clear about that from peering through the call tree. Anyway it's certainly a weakness of the document. This at least stops the error from the return values. Index: pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- pci_mapreg_map.923 Feb 2019 04:54:25 - 1.1 +++ pci_mapreg_map.910 Jan 2022 09:13:30 - @@ -135,12 +135,14 @@ referenced by .Fa reg . .Sh RETURN VALUES .Nm pci_mapreg_map , -.Nm pci_mapreg_info , and -.Nm pci_mapreg_probe +.Nm pci_mapreg_info return 0 on success, or an .Xr errno 2 style value on failure. +.Pp +.Nm pci_mapreg_probe +returns 1 if if the BAR is implemented, 0 if not. .Pp .Nm pci_mapreg_type returns either -- Ted Bullock
Documentation error in pci_mapreg_probe(9)
The manpage incorrectly describes the behaviour and usage of pci_mapreg_probe(9). This function does not return 0 for success and !0 for failure as described in the manual, see the diff below for a possible re-wording and corrected description. Index: share/man/man9/pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1 +++ share/man/man9/pci_mapreg_map.9 8 Jan 2022 20:36:07 - @@ -127,20 +127,34 @@ pointers. .Nm pci_mapreg_probe attempts to determine if the BAR referenced by .Fa reg -describes a valid register mapping. +describes a valid register mapping. If the mapping is valid the register type +will be updated via the pointer +.Fa *typep +to either +.Dv PCI_MAPREG_TYPE_IO +or +.Dv PCI_MAPREG_TYPE_MEM . +If the mapping is invalid the register type should not be used. +.Fa *typep +can be +.Dv NULL +if determining the register type is not desired. .Pp .Nm pci_mapreg_type returns the type of register access for the registers at the BAR referenced by .Fa reg . .Sh RETURN VALUES -.Nm pci_mapreg_map , -.Nm pci_mapreg_info , -and -.Nm pci_mapreg_probe -return 0 on success, or an +.Nm pci_mapreg_map and +.Nm pci_mapreg_info +return zero on success, or an .Xr errno 2 style value on failure. +.Pp +.Nm pci_mapreg_probe +returns zero when no register is found or one if it finds a +register at the BAR referenced by +.Fa reg . .Pp .Nm pci_mapreg_type returns either -- Ted Bullock
PCI configuration space documentation question
I'm reading pci_mapreg_type(9) and I'm wondering about the returns of this function. The documentation says it can return either PCI_MAPREG_TYPE_IO or PCI_MAPREG_TYPE_MEM. But I also see at least one driver checking the type for PCI_MAPREG_MEM_TYPE_64BIT Looking at the definitions of these in sys/dev/pci/pcireg.h I see the two defines listed above but also some others that seem specific to memory mapped registers. #define PCI_MAPREG_TYPE(mr) \ ((mr) & PCI_MAPREG_TYPE_MASK) #define PCI_MAPREG_TYPE_MASK0x0001 #define PCI_MAPREG_TYPE_MEM 0x #define PCI_MAPREG_TYPE_IO 0x0001 #define PCI_MAPREG_MEM_TYPE(mr) \ ((mr) & PCI_MAPREG_MEM_TYPE_MASK) #define PCI_MAPREG_MEM_TYPE_MASK0x0006 #define PCI_MAPREG_MEM_TYPE_32BIT 0x #define PCI_MAPREG_MEM_TYPE_32BIT_1M0x0002 #define PCI_MAPREG_MEM_TYPE_64BIT 0x0004 So, I am curious about the correct way to be using these, pci_mapreg_type(9) doesn't seem to light the way very far here. Please send help I'm in a maze of twisty little passages, all alike. -- Ted Bullock
Re: power of 2 revisited
On 2021-12-29 10:18 p.m., Jonathan Gray wrote:
> On Wed, Dec 29, 2021 at 09:27:34PM -0700, Ted Bullock wrote:
>> This is around documenting peculiar behaviour around power of 2 math in
>> the kernel.
>>
>> I'm wondering if it's worth documenting the peculiarities here, and
>> possibly putting an actually mathematically correct check somewhere in
>> the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED
>> functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n).
>>
>> Is this at all worthwhile? Maybe this would help stop people from
>> incorrectly reinventing the wheel?
>>
>> For instance in the kernel right now there is :
>> radeon_check_pot_argument
>> IS_POWER_OF_2
>> is_power_of_2
>> is_power_of_2_u64
>> powerof2
>> probably others too.
>
> IS_POWER_OF_2 and is_power_of_2_u64 are inteldrm specific
> is_power_of_2 is a linux interface.
>
> radeon_check_pot_argument should be replaced in linux by
> is_power_of_2.
> https://lists.freedesktop.org/archives/amd-gfx/2021-December/073108.html
>
> No code outside of drm should be using the linux interfaces and
> I don't think we should be documenting them.
I've taken some time to write what I believe is correct implementations
of the power of two tests for both signed and unsigned cases and written
a manual for both the original powerof2() macro and my functions. Unlike
the macro these actually give the correct response for 0 and INT_MIN. I
also performed a fairly extensive namespace collision search and didn't
find any function name collisions but this was not exhaustive.
The goal here is to provide a mathematically correct power of two test
and associated documentation. I put the new tests in sys/params.h
because the old (inaccurate) test from bsd 4.3 tahoe has the macro
there.
I deliberately did not correct the logic of the macro as per the thread
years ago here : https://marc.info/?t=14432152764=1=2
I used int for the return type though in the c99 era it could be bool I
suppose; maybe 23 years since that standard was published is too soon to
use bool. :P
I hope that people can use this. Please review.
I wrote a short test program to verify I'm not crazy as well. Here are
the results:
Calculating powers of two:
powerof2(INT_MIN): true
powerof2(-2): false
powerof2(0): true
powerof2(2): true
powerof2(4): true
powerof2(8): true
powerof2(16): true
powerof2(INT_MAX): false
isupow2(0): false
isupow2(2): true
isupow2(4): true
isupow2(8): true
isupow2(16): true
isupow2(77): false
isupow2(UINT_MAX): false
isnpow2(INT_MIN): false
isnpow2(-2): false
isnpow2(0): false
isnpow2(2): true
isnpow2(4): true
isnpow2(8): true
isnpow2(16): true
isnpow2(INT_MAX): false
Index: sys/sys/param.h
===
RCS file: /cvs/src/sys/sys/param.h,v
retrieving revision 1.135
diff -u -p -u -p -r1.135 param.h
--- sys/sys/param.h 19 Sep 2021 16:55:01 - 1.135
+++ sys/sys/param.h 31 Dec 2021 00:33:45 -
@@ -186,7 +186,17 @@
#definehowmany(x, y) (((x)+((y)-1))/(y))
#endif
#defineroundup(x, y) x)+((y)-1))/(y))*(y))
-#define powerof2(x)x)-1)&(x))==0)
+#definepowerof2(x) x)-1)&(x))==0)
+static inline int
+isupow2(uint64_t u)
+{
+ return ((u & (u - 1)) == 0) && (u != 0);
+}
+static inline int
+isnpow2(int64_t n)
+{
+ return ((n & (n - 1)) == 0) && (n > 0);
+}
/* Macros for min/max. */
#defineMIN(a,b) (((a)<(b))?(a):(b))
Also inline here is the complete text of the manual I wrote:
.\" Copyright (c) 2021 Ted Bullock
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $\Mdocdate$
.Dt powerof2 3
.Os
.Sh NAME
.Nm powerof2
.Nm isupow2
.Nm is2pow2
.Nd tests integer for power of two
.Sh SYNOPSIS
.In sys/params.h
.Fd #define powerof2(x) x)-1)&(x))==0)
.Ft int
.Fo isupow2
.Fa "uint64_t"
.Fc
.Ft int
.Fo isnpow2
.Fa "int64_t"
.Fc
.Sh DESCRIPTION
These tests check if an integer value is a power of two.
.Pp
The
.Fn powerof2
macro expands to a l
power of 2 revisited
This started out as a direct question to Ingo, but I have readdressed it to misc@ This is around documenting peculiar behaviour around power of 2 math in the kernel. I noticed that in sys/dev/pci/drm/radeon/radeon_device.c:1137 there is a call to radeon_check_pot_argument, this function isn't correct in that it returns true for a value of zero (as you know, 0 is not a power of two). I sent a diff to Jonathan to correct the behaviour which he rejected because he doesn't want to add local changes to change behaviour which isn't hitting a bug here. Fair Enough. Then reading through old mail archives I came across this discussion from a few years back: https://marc.info/?t=14432152764=1=2 I'm wondering if it's worth documenting the peculiarities here, and possibly putting an actually mathematically correct check somewhere in the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n). Is this at all worthwhile? Maybe this would help stop people from incorrectly reinventing the wheel? For instance in the kernel right now there is : radeon_check_pot_argument IS_POWER_OF_2 is_power_of_2 is_power_of_2_u64 powerof2 probably others too. And manual checks like sys/arch/amd64/amd64/identcpu.c:804 powerof2 = ((x - 1) & x) == 0; -- Ted Bullock
Re: Variable Length Arrays
The 2015-01-02, Theo de Raadt wrote: So what do you guys think? VLA's, are they good, bad, evil, stupid, all of the above? alloca() re-invented. alloca(3) was considered slightly unsafe, because use if it was rare. Your mail strikes so widely, feel free to modify a whole system to use this instead of malloc. Then argue your point, and lose... Thanks, more or less sums it up. I'll stick to using malloc and friends; it's got a reliable idiom for checking errors, and I have a lot of appreciation for the rigor that's gone into the implementation. -- Ted Bullock
Variable Length Arrays
Hey Folks, So I've been wondering about variable length arrays from c99 for a while now. They seem to me like a good way to avoid lots of trivial calls to malloc/free at least for smaller arrays that aren't going to blow up the stack. That said I don't see them being used. The promise of them seems to be 'easy', dynamic, stack allocated memory and improved readability. That said, using vla's avoids the work on malloc that creates a hostile (strict) environment, like junking and whatnot. Also there is the portability stuff, I'm not sure if all the platforms that openbsd runs on are using a compiler that supports them yet. gcc 4.2 in base seems to support them well enough, though I note that the gcc website says that some corner cases were fixed in version 4.5 which I haven't investigated yet. So what do you guys think? VLA's, are they good, bad, evil, stupid, all of the above? -- Ted Bullock
Re: pf+voip
On 2014-05-28 6:39 AM, pae3 wrote: Hi! Don't miss RTP protocol : pass proto tcp to port 20001 ah, no RTP will be moving over UDP. -- Ted Bullock tbull...@northernartifex.com
Re: LibreSSL @ BSDCan 2014
Real actual bob becks giving real actual ssl video chat http://m.youtube.com/watch?v=GnBbhXBDmwU Sent from my BlackBerry 10 smartphone on the Fido network. Original Message From: ropers Sent: Saturday, May 17, 2014 7:05 PM To: staticsafe Cc: misc@openbsd.org Subject: Re: LibreSSL @ BSDCan 2014 Was this recorded? Is there audio or video of that online anywhere? On 18 May 2014 00:43, staticsafe m...@staticsafe.ca wrote: This might be of interest: http://www.openbsd.org/papers/bsdcan14-libressl/ -- staticsafe https://asininetech.com
Keeping a carp backup connected to the internet
CARP(ish) Question: I have a /30 transit network from my ISP, where there obviously isn't room for both routers in the carp setup to have a dedicated IP address in addition to the IP assigned to the carp interface. If it matters, I've assigned both routers private addresses in my network and can talk to them just fine on the local network. Anyway, I've noticed that the clock on the backup router is getting slowly out of sync. I figure it cannot initiate network sessions to the public ntp pool since it doesn't have an IP and a valid route to the internet while it's acting as the backup. I'd prefer to not run yet another service locally if at all possible though. I'm wondering what other folks do in this situation. -- Ted Bullock tbull...@northernartifex.com
Re: Proliant DL380 G3 cannot get on network
On Wed, Jan 6, 2010 at 3:02 PM, Mauro Rezzonico l...@ch23.org wrote: Ted Bullock wrote: I am trying to install OpenBSD 4.6 on an older DL380 G3, and am unable to get an address from DHCP using the onboard network adapter. OpenBSD 4.6 has been released with broken support for bge, you must update to a snapshot from October at least... Yay it works! Neat. Later, -- Ted Bullock tbull...@comlore.com
Proliant DL380 G3 cannot get on network
I am trying to install OpenBSD 4.6 on an older DL380 G3, and am unable to get an address from DHCP using the onboard network adapter. The install just repeats the DHCPDISCOVER message over and over. Here is the some of the dmesg (hand typed unfortunately) bge0 at pci4 dev 1 function 0 Broadcom BCM5703X rev 0x02, BCM5703 A2 (0x1002): apic 3 int 13 (irq 11), address 00:0b:03:c1:1f brgphy0 at bge0 phy 1: BCM5703 10/100/1000baseT PHY, rev. 2 bge1 at pci4 dev 2 function 0 Broadcom BCM5703X rev 0x02, BCM5703 A2 (0x1002): apic 3 int 13 (irq 11), address 00:0b:03:c1:1e brgphy1 at bge1 phy 1: BCM5703 10/100/1000baseT PHY, rev. 2 Note that only bge1 is currently physically connected however the results are the same irregardless of which adapter is used. Running ifconfig bge1 from the install shell gives: bge1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0b:cd:03:c1:1e media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet6 fe80::20b:cdff:fe03:c11e%bge1 prefixlen 64 scopeid 0x2 -- Ted Bullock tbull...@comlore.com
Re: Proliant DL380 G3 cannot get on network
On Tue, Jan 5, 2010 at 5:32 PM, Aaron Mason simplersolut...@gmail.com wrote: What happens if you set a static IP? Can it talk to the network then? Even with a static address packets do not seem to be flowing. ifconfig reports the following after statically allocating an address: inet 192.168.15.97 netmask 0xff00 broadcast 192.168.15.255 When I ping the gateway or any other host on the network I get the following: PING 192.168.15.1 (192.168.15.1): 56 data bytes ping: sendto: Host is down ping: wrote 192.168.15.1 64 chars, ret=-1 . . etc with 100% packet loss Also, there's been reports of bge devices getting hit with watchdog timeouts, do you see any of these? Nothing is jumping out at me here Also, you might want to invest in a null modem cable and set your system to talk to the serial port if one is available. I have one, it's just not convenient for me to get it at the moment. -- Ted Bullock tbull...@comlore.com
Re: Quad ethernet card
Dave Harrison wrote: However I'm not aware of any tools that handle that kind of distributed benchmark.. anyone ? httperf can be run in an array of clients (--client option), although there is currently no way to automatically aggregate the results. -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering Bike Across Canada Adventure http://www.comlore.com/bike
Re: OpenBSD sucks
Darrin Chandler wrote: On Fri, Jun 01, 2007 at 12:44:10PM +1000, Damien Miller wrote: On Thu, 31 May 2007, Open Phugu wrote: On 5/31/07, qw er [EMAIL PROTECTED] wrote: It really sucks. it is slow. What you say does not apply to OpenBSD. What you said describes you. I find it amazing that, in 2007, people still respond to the most blatant trolling in exactly the way that the troll wants. Human nature won't change until 2008. Sorry. To summarize... People are a Problem -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering Bike Across Canada Adventure http://www.comlore.com/bike
Re: OpenBSD sucks
Steve Shockley wrote: qw er wrote: It really sucks. it is slow. Not any more: http://marc.info/?m=118046279204104 . That is too bad since I am one of those rare people sniff -Ted -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering Bike Across Canada Adventure http://www.comlore.com/bike
Re: OpenBSD sucks
Ted Unangst wrote: you should have sent in your dmesg then. hardware that doesn't get reported doesn't exist. This is not really that big a deal to me. I certainly don't want to stand in the way of progress just because I maintain an old 386 as a hobby. I will send in the dmesg though, next time I boot it up. -Ted -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering Bike Across Canada Adventure http://www.comlore.com/bike
Re: Problem installing 4.1/sparc64 on Sun Blade 100
I had the same problem until I updated the firmware to 4.17.1 -Ted Landry Breuil wrote: Hello, i'm trying to install OpenBSD/Sparc64 on a Blade 100, tried various methods/versions (all described in INSTALL.sparc64), they all fail after 'Trying bsd' and stall. Where can i have a start point to debug what happens/doesn't happen ? I've tried : - 3.9-release Cdrom (original version from wim) - 4.1-release cd41.iso taken from mirror/4.1 - 4.1-current cd41.iso taken from snapshots - knowing cd-install are not really good on blades, i tried netbooting bsd.rd 4.1-release and -current, using another obsd box as rarpd/tftpd/rpc.bootparamd/nfsd/mountd server, set like described in diskless(8). The weird thing is that ofwboot.net is taken from tftpd after 'boot net bsd.rd', ran, i see the first twolines : OpenBSD 4.1 (obj) #0: -build-date- [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC then Trying bsd and stalled-nothing more on the screen. but i see no mount requests in mountd -d output. i tried following https://www-s.acm.uiuc.edu/wiki/comments/OpenBSD+Sparc64#notes documentation too. security-mode is set to none in OBP, and firmware version is 4.0.45, i don't think it needs a firmware upgrade. Could it be a hardware problem ? How can i get more debug information ? Thanks for any hints. Next step will be trying to use a floppy (gee, i have to find a floppy reader and a disk), or putting the disk in my U10 (which works fine) and try to do the install on it. Landry . -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering Bike Across Canada Adventure http://www.comlore.com/bike
pkg-config .pc files for default libraries
I really like the new pkg-config tool in 4.1 and want to use it more in my own software. My only problem with it is that there is no pkg-config .pc files for the default libraries (eg openssl) in the default install. For example, with openssl libcrypto and libssl go hand in hand. pkg-config could be easily used to test and identify this. Is it worthwhile to have a /usr/lib/pkgconfig directory for the default library packages? -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering Bike Across Canada Adventure http://www.comlore.com/bike
Re: hackathon
Theo de Raadt wrote: One very important part of the hackathon sub-project will be to improve 10Gb support. Some of us believe that measuring the performance of 10Gb networking later will help us spot some performance problems that can improve 1Gb ethernet speed. As a side note, we recently released a new version of httperf that now builds cleanly on OpenBSD. It can be used to measure web system performance (including throughput). My documentation on the tool is available here http://www.comlore.com/httperf The official website is available here http://www.hpl.hp.com/research/linux/httperf/ Hope it can be of some sort of use in identifying performance bottlenecks. -Ted -- Theodore Bullock, [EMAIL PROTECTED], [EMAIL PROTECTED] B.Sc Software Engineering GPG Fingerprint = 3B8E 8B0E D296 AACB 7BE2 24F2 1006 B7BE C8AC 5109
