Christos Margiolis: technology

Configuring Gmail and Outlook365 on Neomutt

Tue, 18 Mar 2025 00:00:00 +1200

Gmail

First enable two-factor authentication on your Google account settings, and then create an application password for Neomutt.

Once you have the app password, you can store it in your password manager ~~(or expose it in plain-text)~~. I personally use pass, which is what my example configurations below also use:

$ pass add gmail

Create ~/.config/mutt/yourname@gmail.com [1]:

set from = "Your Name <yourname@gmail.com>"
set realname = "Your Name"
set imap_user = "yourname@gmail.com"

set smtp_url = "smtps://yourname@gmail.com@smtp.gmail.com:465/"
set folder = "imaps://imap.gmail.com:993/"

set smtp_authenticators = "gssapi:login"
set ssl_starttls = yes
set ssl_force_tls = yes

set my_pass = "`pass gmail`"
set imap_pass = $my_pass
set smtp_pass = $my_pass

set spoolfile = "+INBOX"
set record = "+[Gmail]/Sent Mail"
set postponed = "+[Gmail]/Drafts"
set trash = "+[Gmail]/Trash"

mailboxes =INBOX ="[Gmail]/Sent Mail" =[Gmail]/Drafts =[Gmail]/Spam =[Gmail]/Trash

Source the email configuration in ~/.config/mutt/muttrc:

source ~/.config/mutt/yourname@gmail.com
folder-hook "yourname@gmail.com" "source ~/.config/mutt/yourname@gmail.com"

Outlook365

Add your Outlook password to your password manager:

$ pass add outlook

Generate an OAuth2 token [2]. The client-id we are using here is Thunderbird’s:

$ /usr/local/share/neomutt/oauth2/mutt_oauth2.py \
	-v \
	-t \
	--authorize \
	--client-id "9e5f94bc-e8a4-4e73-b8be-63364c29d753" \
	--client-secret "" \
	--email "yourname@outlook.com" \
	--provider microsoft \
	~/.config/mutt/outlooktoken

When prompted, choose authcode as the “OAuth2 flow”. As for “client secret”, leave it empty. The script should then point you to a URL which will take you to the Outlook365 login page. Onced logged in, you will be redirected to a URL which includes the authorization code needed by the script. Because it might be hard to filter out the code by hand, you can copy the whole URL and run the following command to get the code:

$ echo "the_url" | sed 's/.*code=//;s/\&.*//'

Paste the output of this command to the script prompt when asked, and press enter.

Create ~/.config/mutt/yourname@outlook.com [1]:

set from = "Your Name <yourname@outlook.com>"
set realname = "Your Name"
set imap_user = "yourname@outlook.com"

set smtp_url = "smtp://yourname@outlook.com@smtp.office365.com:587"
set folder = "imaps://yourname@outlook.com@outlook.office365.com"

set smtp_authenticators = "xoauth2"
set imap_authenticators = "xoauth2"
set ssl_starttls = yes
set ssl_force_tls = yes

set my_pass = "`pass outlook`"
set imap_pass = $my_pass
set smtp_pass = $my_pass

set imap_oauth_refresh_command = "/usr/local/share/neomutt/oauth2/mutt_oauth2.py ~/.config/mutt/outlooktoken"
set smtp_oauth_refresh_command = "/usr/local/share/neomutt/oauth2/mutt_oauth2.py ~/.config/mutt/outlooktoken"

set spoolfile = "+INBOX"
set record = "+Sent Items"
set postponed = "+Drafts"
set trash = "+Deleted Items"

mailboxes =INBOX ="Sent Items" =Drafts ="Deleted Items"

Source the email configuration in ~/.config/mutt/muttrc:

source ~/.config/mutt/yourname@outlook.com
folder-hook "yourname@outlook.com" "source ~/.config/mutt/yourname@outlook.com"

Notes

If you want to add more mailboxes, you can append them to mailboxes like so: =MailboxName.
The paths for mutt_oauth2.py might differ depending on the operating system. For example, on FreeBSD it’s /usr/local/share/neomutt/oauth2/mutt_oauth2.py, but on Linux, it’s usually /usr/share/neomutt/oauth2/mutt_oauth2.py.

PostgreSQL 15 and pgAdmin4 on FreeBSD

Thu, 07 Sep 2023 00:00:00 +1200

Tested on FreeBSD 13.2. This article is also mirrored on the FreeBSD Wiki.

PostgreSQL

Install PostgreSQL:

# pkg install postgresql15-server postgresql15-client

Enable the PostgreSQL service:

# sysrc postgresql_enable="YES"

Initialize PostgreSQL and start the service:

# /usr/local/etc/rc.d/postgresql initdb
# service postgresql start

Make sure the service is running properly on IPv4 and IPv6 port 5432:

$ sockstat -46 | grep 5432

Set a password for the default postgres user:

# passwd postgres

Create an owner user for your database:

# su - postgres
$ createuser admin
$ createdb foo_db -O admin

Inside the psql prompt, set an encrypted password for admin and grant exclusive access to foo_db to the admin user:

$ psql foo_db
foo_db=# alter role admin with encrypted password 'yourpassword';
foo_db=# grant all privileges on database foo_db to admin;
foo_db=# exit
$ exit

Make PostgreSQL listen to all addresses, instead of just localhost.

# vi /var/db/postgres/data15/postgresql.conf

Uncomment the listen_addresses line and set it to:

listen_addresses = '*'

Change the security settings:

# vi /var/db/postgres/data15/pg_hba.conf

Go to the bottom of the file and set trust to md5 for all existing entries:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     md5
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     md5
host    replication     all             127.0.0.1/32            md5
host    replication     all             ::1/128                 md5

Also, allow remote IPv4 and IPv6 connections to our new database as admin only:

# Allow remote connections to foo_db as admin
host    foo_db          admin           0.0.0.0/0               md5
host    foo_db          admin           ::/0                    md5

Restart the service:

# serivce postgresql restart

pgAdmin4

Install the needed packages:

# pkg install python py39-pip py39-virtualenv py39-sqlite3 ca_root_nss openjpeg rust

Upgrade pip to the latest version:

$ pip install --upgrade pip

Initialize the virtualenv for pgAdmin4 in your home directory:

$ cd
$ virtualenv pgadmin4

Enter the virtualenv and install pgAdmin4. This will take a while:

$ . pgadmin4/bin/activate
(pgadmin4) $ pip install pgadmin4

Create a local config file:

(pgadmin4) # mkdir -p /var/lib/pgadmin /var/log/pgadmin
(pgadmin4) $ cp pgadmin4/lib/python3.9/site-packages/pgadmin4/config.py pgadmin4/lib/python3.9/site-packages/pgadmin4/config_local.py
(pgadmin4) $ vi pgadmin4/lib/python3.9/site-packages/pgadmin4/config_local.py

Inside config_local.py, edit the following values:

DEFAULT_SERVER = '0.0.0.0'
DEFAULT_SERVER_PORT = 5050

Start pgAdmin4 (always inside the virtualenv) and set up your account:

(pgadmin4) # pgadmin4
Email address: you@mail.com
Password: yourpassword
Retype password: yourpassword

Open a web browser and enter pgAdmin4 (replace the IP with the appropriate one) and log in with the email and password you just entered in the pgadmin4 prompt:

http://192.168.1.11:5050

Inside the web interface, go to File -> Preferences -> Binary Paths and under the PostgreSQL Binary Path section, check PostgreSQL 15 and set the binary path to /usr/local/bin/. Then click Save.

From now on, you can run pgadmin4 in the background like so:

(pgadmin4) # pgadmin4 &

Upgrading pgAdmin4

To upgrade pgAdmin4, you only have to delete and reinstall the virtualenv:

$ cd
$ rm -rf pgadmin4
$ virtualenv pgadmin4
$ . pgadmin4/bin/activate
(pgadmin4) $ pip install --upgrade pgadmin4

You also have to re-create config_local.py and set DEFAULT_SERVER (see above).

Inline function tracing with the kinst DTrace provider

Tue, 18 Jul 2023 00:00:00 +1200

Quick background

DTrace is a framework that gives administrators and kernel developers the ability to observe kernel behavior in real time. DTrace has modules called “providers”, that perform a particular instrumentation in the kernel (and sometimes userland) using “probes”.

kinst is a new low-level DTrace provider co-authored by Christos Margiolis and Mark Johnston for the FreeBSD operating system, which allows the user to trace arbitrary instructions in kernel functions. It is part of the base system as of FreeBSD 14.0.

kinst probes take the form of kinst::<function>:<instruction>, where <function> is the kernel function to be traced, and <instruction> is the offset to the instruction, relative to the beginning of the function, and can be obtained from the function’s disassembly. If the <instruction> field is left empty, kinst will trace all instructions in that function. Unlike FBT, kinst can also trace the entry and return points of inline functions (see Inline function tracing).

The origin of the name is inspired from an early paper written by A. Tamches and B. Miller discussing a tracing tool they developed called “KernInst”.

Usage

Find the offset corresponding to the third instruction in vm_fault() and trace it, printing the contents of the RSI register:

# kgdb
(kgdb) disas /r vm_fault
Dump of assembler code for function vm_fault:
   0xffffffff80f4e470 <+0>:     55      push   %rbp
   0xffffffff80f4e471 <+1>:     48 89 e5        mov    %rsp,%rbp
   0xffffffff80f4e474 <+4>:     41 57   push   %r15
...

# dtrace -n 'kinst::vm_fault:4 {printf("%#x", regs[R_RSI]);}'
  2  81500                       vm_fault:4 0x827c56000
  2  81500                       vm_fault:4 0x827878000
  2  81500                       vm_fault:4 0x1fab9bef0000
  2  81500                       vm_fault:4 0xe16cf749000
  0  81500                       vm_fault:4 0x13587c366000
  ^C

Trace the return point of critical_enter(), which is an inline function:

# dtrace -n 'kinst::critical_enter:return'
dtrace: description 'kinst::critical_enter:return' matched 130 probes
CPU     ID                    FUNCTION:NAME
  1  71024                spinlock_enter:53
  0  71024                spinlock_enter:53
  1  70992                uma_zalloc_arg:49
  1  70925    malloc_type_zone_allocated:21
  1  70994                uma_zfree_arg:365
  1  70924             malloc_type_freed:21
  1  71024                spinlock_enter:53
  0  71024                spinlock_enter:53
  0  70947         _epoch_enter_preempt:122
  0  70949           _epoch_exit_preempt:28
  ^C

Inline function tracing

How it works

To trace inline functions, libdtrace makes use of the DWARF Debugging Standard, to detect if the function specified is an inline call. If it is, D syntax is transformed to create kinst probes for each of the inline copies found. All work is done in libdtrace, instead of kinst(4). This feature has been added to FreeBSD with this patch.

Contrary to how kinst expects a <function>:<instruction> tuple to create probes, for inline functions, <instruction> is replaced by entry and return.

Syntactic transformations

Suppose the user wants to trace a probe of the form:

kinst::<func>:<entry|return>
/<pred>/
{
	<acts>
}

libdtrace sees that we have specified entry or return, instead of an offset, which is what a regular kinst probe would look like, so it loops through all loaded kernel modules and parses their DWARF and ELF info to see if this function is an inline — if not, the probe is converted to an FBT one, so that we don’t duplicate FBT’s functionality in kinst:

# dtrace -dn 'kinst::malloc:entry {exit(0);}'
fbt::malloc:entry
{
        exit(0x0);
}

dtrace: description 'kinst::malloc:entry ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  2  31144                     malloc:entry

If the function however is an inline, libdtrace will find all calls refering to this function and create new probes for each one of the inline copies found.

# dtrace -dn 'kinst::cam_iosched_has_more_trim:entry { printf("\t%d\t%s", pid, execname); }'
kinst::cam_iosched_get_trim:13,
kinst::cam_iosched_next_bio:13,
kinst::cam_iosched_schedule:40
{
	printf("\t%d\t%s", pid, execname);
}

dtrace: description 'kinst::cam_iosched_has_more_trim:entry ' matched 4 probes
CPU     ID                    FUNCTION:NAME
  0  81502          cam_iosched_schedule:40     2       clock
  0  81501          cam_iosched_next_bio:13     2       clock
  2  81502          cam_iosched_schedule:40     2       clock
  1  81502          cam_iosched_next_bio:13     0	kernel
  1  81503          cam_iosched_schedule:40     0	kernel
^C

There can also be both inline and non-inline definitions of the same function. In this case, kinst creates an additional FBT probe for the non-inline definition.

The -d flag used in these examples to dump the D script after libdtrace has applied syntactic transformations, has been added to DTrace in commit 1e136a9cbd3a.

Heuristic for calculating the `entry` and `return` offsets

libdtrace reuses parts of the mechanism implemented in my inlinecall(1) program, which finds and prints all call sites of a given inline function:

$ ./inlinecall vm_page_mvqueue /usr/lib/debug/boot/kernel/kernel.debug
/usr/src/sys/vm/vm_page.c:4142
        [0xffffffff80f91541 - 0xffffffff80f91599]       /usr/src/sys/vm/vm_page.c:4195  vm_page_readahead_finish()
        [0xffffffff80f915f5 - 0xffffffff80f91603]       /usr/src/sys/vm/vm_page.c:4195  vm_page_readahead_finish()
        [0xffffffff80f9163d - 0xffffffff80f916c2]       /usr/src/sys/vm/vm_page.c:4184  vm_page_activate()
        [0xffffffff80f916cd - 0xffffffff80f916e5]       /usr/src/sys/vm/vm_page.c:4184  vm_page_activate()
        [0xffffffff80f916fe - 0xffffffff80f91747]       /usr/src/sys/vm/vm_page.c:4195  vm_page_deactivate()
        [0xffffffff80f91750 - 0xffffffff80f91768]       /usr/src/sys/vm/vm_page.c:4195  vm_page_deactivate()
        [0xffffffff80f94a59 - 0xffffffff80f94aa9]       /usr/src/sys/vm/vm_page.c:4195  vm_page_reclaim_contig_domain()
        [0xffffffff80f94de4 - 0xffffffff80f94df9]       /usr/src/sys/vm/vm_page.c:4195  vm_page_reclaim_contig_domain()
        [0xffffffff80f9661e - 0xffffffff80f96667]       /usr/src/sys/vm/vm_page.c:4202  vm_page_deactivate_noreuse()
        [0xffffffff80f96670 - 0xffffffff80f96688]       /usr/src/sys/vm/vm_page.c:4202  vm_page_deactivate_noreuse()
        [0xffffffff80f9669e - 0xffffffff80f966ea]       /usr/src/sys/vm/vm_page.c:4212  vm_page_launder()
        [0xffffffff80f966f3 - 0xffffffff80f9670b]       /usr/src/sys/vm/vm_page.c:4212  vm_page_launder()
        [0xffffffff80f96d4c - 0xffffffff80f96dac]       /usr/src/sys/vm/vm_page.c:4212  vm_page_advise()
        [0xffffffff80f96dac - 0xffffffff80f96e07]       /usr/src/sys/vm/vm_page.c:4202  vm_page_advise()

Most of the entries above appear twice but with different boundaries:

        [0xffffffff80f9163d - 0xffffffff80f916c2]       /usr/src/sys/vm/vm_page.c:4184  vm_page_activate()
        [0xffffffff80f916cd - 0xffffffff80f916e5]       /usr/src/sys/vm/vm_page.c:4184  vm_page_activate()

This means that the inline copy’s boundaries are split into more than one parts, which can be caused by having early returns inside the inline function. By using this assumption, we can deduce that the entry point of the function is 0xffffffff80f9163d, and each of the upper boundaries are the return points (i.e., 0xffffffff80f916c2 and 0xffffffff80f916e5), so we end up with one entry and two return trace points.

However, this is not exactly true, because the final return address given by DWARF corresponds to the instruction after the actual return instruction. We can verify this in GDB using the two return addresses from the example above:

# kgdb
(kgdb) disas vm_page_activate
...
   0xffffffff80f916c0 <+144>:   jmp    0xffffffff80f91673 <vm_page_activate+67>
   0xffffffff80f916c2 <+146>:   add    $0x8,%rsp			<-- first address given by DWARF
...
   0xffffffff80f916e0 <+176>:   call   0xffffffff80bed360 <panic>	<-- last instruction
									<-- second address should be here

It turns out that 0xffffffff80f916e5 is, in fact, outside vm_page_activate() altogether!

(kgdb) x/i 0xffffffff80f916e5
   0xffffffff80f916e5:  data16 cs nopw 0x0(%rax,%rax,1)

After running a couple of tests, I came to the conclusion that there are two possible cases with return addresses:

If the inline copy’s DIE has DW_AT_lowpc and DW_AT_highpc set, the return address is always outside the inline function’s boundaries.
If the inline copy’s DIE has DW_AT_ranges set, only the last return address is outside the inline function’s boundaries.
Combining the two bullets above, if the return address of the inline function is the same as the upper boundary of the caller function, it’s outside both the inline copy’s and the caller function’s boundaries.

In order to fix this, we have to go one instruction back whenever we come across one of those 3 cases.

Finally the entry offset is calculated as:

inline_bound_lo - caller_bound_lo

And the return one, including the modifications (if any) discussed above, as:

inline_bound_hi - caller_bound_lo

These offsets are then used to create regular kinst probes of the form kinst::<func>:<instruction>, which is what kinst actually expects:

# dtrace -dn 'kinst::vm_page_mvqueue:entry,kinst::vm_page_mvqueue:return'
dtrace: description 'kinst::vm_page_mvqueue:entry,kinst::vm_page_mvqueue:return' matched 22 probes
kinst::vm_page_readahead_finish:33,
kinst::vm_page_readahead_finish:121,
kinst::vm_page_activate:13,
kinst::vm_page_deactivate:14,
kinst::vm_page_reclaim_contig_domain:1961,
kinst::vm_page_deactivate_noreuse:14,
kinst::vm_page_launder:14,
kinst::vm_page_advise:236,
kinst::vm_page_advise:332,
kinst::vm_page_readahead_finish:220,
kinst::vm_page_activate:146,
kinst::vm_page_activate:176,
kinst::vm_page_deactivate:87,
kinst::vm_page_deactivate:115,
kinst::vm_page_reclaim_contig_domain:2041,
kinst::vm_page_reclaim_contig_domain:2884,
kinst::vm_page_deactivate_noreuse:87,
kinst::vm_page_deactivate_noreuse:115,
kinst::vm_page_launder:90,
kinst::vm_page_launder:118,
kinst::vm_page_advise:330,
kinst::vm_page_advise:421
{
}

CPU     ID                    FUNCTION:NAME
  3  95381              vm_page_activate:13 
  3  95389             vm_page_activate:146 
  2  95381              vm_page_activate:13 
  2  95389             vm_page_activate:146 
  1  95387               vm_page_advise:332 
  1  95400               vm_page_advise:421 
  1  95387               vm_page_advise:332 
  1  95400               vm_page_advise:421 
  1  95387               vm_page_advise:332 
^C

Using DWARF to find call sites of inline functions

Tue, 07 Feb 2023 00:00:00 +1200

What is DWARF?

From the DWARF Debugging Standard’s documentation:

This document defines a format for describing programs to facilitate user source level debugging. This description can be generated by compilers, assemblers and linkage editors. It can be used by debuggers and other tools.

Debugging information entries (DIEs) are represented as a tree, one per compilation unit (CU). Each DIE has a tag (DW_TAG_*, see DWARF PDF Figure 1) denoting its class, and attributes (DW_AT_*, see DWARF PDF Figure 2) denoting its various characteristics, associated with it.

The next entry of a DIE is a child DIE. If a DIE doesn’t have children, the next entry is a “sibling”.

Consider the following structure:

CU1 (DW_TAG_compile_unit)
	func1 (DW_TAG_subprogram)
		DW_AT_foo
		DW_AT_bar
		func2 (DW_TAG_subprogram)
			DW_AT_foo
			DW_AT_bar
	myvar (DW_TAG_variable)
		DW_AT_foo
		DW_AT_bar
CU2 (DW_TAG_compile_unit)
	...

CU1 has func1 and myvar as chidren and CU2 as siblings. func1 has func2 as a child.

The debug file can be generated by compiling with the -g option. To dump DWARF info you can use readelf -wi <file> and dwarfdump <file>.

Inline functions in DWARF

DIEs of inline function declarations have the DW_TAG_subprogram tag and the DW_AT_inline attribute. DIEs of inline copies of this function will have the DW_TAG_inlined_subroutine tag.

Attributes inline copies can have include:

DW_AT_abstract_origin: DIE offset to the inline declaration.
DW_AT_call_file: Integer denoting the file the function is called in.
DW_AT_call_line: File line.
DW_AT_call_column: File column.
DW_AT_low_pc and DW_AT_high_pc: Lower and upper call boundaries. Explained in the next section.
DW_AT_ranges: Explained in the next section.

For example, if we dump the DWARF info for my FreeBSD kernel:

$ readelf -wi /usr/lib/debug/boot/kernel/kernel.debug > ~/foo

We find that vfs_freevnodes_dec gets inlined:

 <1><1dfa144>: Abbrev Number: 94 (DW_TAG_subprogram)
    <1dfa145>   DW_AT_name        : (indirect string) vfs_freevnodes_dec
    <1dfa149>   DW_AT_decl_file   : 1
    <1dfa14a>   DW_AT_decl_line   : 1447
    <1dfa14c>   DW_AT_prototyped  : 1
    <1dfa14c>   DW_AT_inline      : 1

Inline copies will have DW_AT_abstract_origin point to the declaration’s DIEs offset, in this case 0x1dfa144. If we look for 0x1dfa144, we do indeed find a few inline copies.

 <3><1dfe45e>: Abbrev Number: 24 (DW_TAG_inlined_subroutine)
    <1dfe45f>   DW_AT_abstract_origin: <0x1dfa144>
    <1dfe463>   DW_AT_low_pc      : 0xffffffff80cf701d
    <1dfe46b>   DW_AT_high_pc     : 0x38
    <1dfe46f>   DW_AT_call_file   : 1
    <1dfe470>   DW_AT_call_line   : 3458
    <1dfe472>   DW_AT_call_column : 5

 <3><1dfd2e2>: Abbrev Number: 58 (DW_TAG_inlined_subroutine)
    <1dfd2e3>   DW_AT_abstract_origin: <0x1dfa144>
    <1dfd2e7>   DW_AT_ranges      : 0x1f1290
    <1dfd2eb>   DW_AT_call_file   : 1
    <1dfd2ec>   DW_AT_call_line   : 3405
    <1dfd2ee>   DW_AT_call_column : 3

  ...there are more

As I described in the first section, a debug file may consist of multiple CUs that define the same inline function. We want treat each CU independently, that is, each inline copy is handled relative to its CU.

Calculating call boundaries

There are 2 cases we have to take care of when calculating the actual call boundaries of an inline copy.

The DIE has `DW_AT_low_pc` and `DW_AT_high_pc`

 <3><1dfe45e>: Abbrev Number: 24 (DW_TAG_inlined_subroutine)
    <1dfe45f>   DW_AT_abstract_origin: <0x1dfa144>
    <1dfe463>   DW_AT_low_pc      : 0xffffffff80cf701d
    <1dfe46b>   DW_AT_high_pc     : 0x38
    <1dfe46f>   DW_AT_call_file   : 1
    <1dfe470>   DW_AT_call_line   : 3458
    <1dfe472>   DW_AT_call_column : 5

In this case, the lower boundary is low_pc and the upper boundary is low_pc + high_pc, which, for the DIE shown in this example, the boundaries are:

low = 0xffffffff80cf701d
high = 0xffffffff80cf701d + 0x38 = 0xffffffff80cf7055

The DIE has `DW_AT_ranges`

 <3><1dfd2e2>: Abbrev Number: 58 (DW_TAG_inlined_subroutine)
    <1dfd2e3>   DW_AT_abstract_origin: <0x1dfa144>
    <1dfd2e7>   DW_AT_ranges      : 0x1f1290
    <1dfd2eb>   DW_AT_call_file   : 1
    <1dfd2ec>   DW_AT_call_line   : 3405
    <1dfd2ee>   DW_AT_call_column : 3

This is a bit more involved. DW_AT_ranges refers to the .debug_ranges section found in debug files. We can dump the ranges:

$ dwarfdump -N /usr/lib/debug/boot/kernel/kernel.debug
.debug_ranges
 Ranges group 0:
                ranges: 3 at .debug_ranges offset 0 (0x00000000) (48 bytes)
                        [ 0] range entry    0x00000019 0x00000073
                        [ 1] range entry    0x0000007e 0x00000106
                        [ 2] range end      0x00000000 0x00000000
 Ranges group 1:
                ranges: 3 at .debug_ranges offset 48 (0x00000030) (48 bytes)
                        [ 0] range entry    0x00000022 0x0000006a
                        [ 1] range entry    0x0000007e 0x00000106
                        [ 2] range end      0x00000000 0x00000000
 ...

If we search for 0x1f1290 (the inline copy’s ranges), we find its range group:

 Ranges group 38809:
                ranges: 3 at .debug_ranges offset 2036368 (0x001f1290) (48 bytes)
                        [ 0] range entry    0x000025c8 0x000025f9
                        [ 1] range entry    0x0000261a 0x00002621
                        [ 2] range end      0x00000000 0x00000000

To get the call boundaries, we add each range entry’s boundaries to the DW_AT_low_pc of the root DIE of the CU. The root DIE is found programmatically, but I happen to know that in this case, the root DIE is:

 <0><1dee9fb>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <1dee9fc>   DW_AT_producer    : (indirect string) FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
    <1deea00>   DW_AT_language    : 12	(C99)
    <1deea02>   DW_AT_name        : (indirect string) /usr/src/sys/kern/vfs_subr.c
    <1deea06>   DW_AT_stmt_list   : 0x6cb448
    <1deea0a>   DW_AT_comp_dir    : (indirect string) /usr/obj/usr/src/amd64.amd64/sys/GENERIC
    <1deea0e>   DW_AT_low_pc      : 0xffffffff80cf4020
    <1deea16>   DW_AT_high_pc     : 0xde3d

Finally, we end up with the following boundaries:

low = 0xffffffff80cf4020 + 0x000025c8 = 0xffffffff80cf65e8
high = 0xffffffff80cf4020 + 0x000025f9 = 0xffffffff80cf6619

low = 0xffffffff80cf4020 + 0x0000261a = 0xffffffff80cf663a
high = 0xffffffff80cf4020 + 0x00002621 = 0xffffffff80cf6641

Finding the caller function

There are cases where we want to know which function an inline function is being called from. Because DWARF does not encode that information, we’ll have to scan ELF symbol tables.

$ readelf -s /usr/lib/debug/boot/kernel/kernel.debug

Since we know the inline copy’s boundaries, we only have to find which symbol’s boundaries the inline copy is inside. In other words, the following condition has to be met:

sym_lower_bound <= inline_lower_bound <= inline_upper_bound <= sym_upper_bound

Because searching through ELF symbol tables manually and doing calculations by hand would take too long, the best way to do this is programmatically through LibELF.

inlinecall(1)

I wrote a little program that does everything I talked about in this post automatically. It works on FreeBSD as-is, and most likely needs some modification to get it to work on other platforms.

The program takes an inline function name and a debug file as arguments:

inlinecall <function> <file>

And outputs the results in the following form:

cu1_func_declaration_file:line
	[low_bound - high_bound]	inline_copy1_file:line	caller_func()
	[low_bound - high_bound]	inline_copy2_file:line	caller_func()
	...
cu2_func_declaration_file:line
	...
...

For example:

$ inlinecall critical_enter /usr/lib/debug/boot/kernel/kernel.debug
/usr/src/sys/sys/systm.h:175
        [0xffffffff809eb51f - 0xffffffff809eb526]       /usr/src/sys/kern/kern_intr.c:1387      intr_event_handle()
/usr/src/sys/sys/systm.h:175
        [0xffffffff80a051f4 - 0xffffffff80a05208]       /usr/src/sys/kern/kern_malloc.c:431     malloc_type_freed()
        [0xffffffff80a0514c - 0xffffffff80a0515b]       /usr/src/sys/kern/kern_malloc.c:388     malloc_type_zone_allocated()
/usr/src/sys/sys/systm.h:175
        [0xffffffff80a263c4 - 0xffffffff80a263d3]       /usr/src/sys/kern/kern_resource.c:509   rtp_to_pri()
/usr/src/sys/sys/systm.h:175
        [0xffffffff80a28f59 - 0xffffffff80a28f5f]       /usr/src/sys/kern/kern_rmlock.c:775     _rm_assert()
        [0xffffffff80a29087 - 0xffffffff80a2908d]       /usr/src/sys/kern/kern_rmlock.c:801     _rm_assert()
        [0xffffffff80a29eb0 - 0xffffffff80a29eb7]       /usr/src/sys/kern/kern_rmlock.c:645     _rm_rlock_debug()
        [0xffffffff80a28c4b - 0xffffffff80a28c5a]       /usr/src/sys/kern/kern_rmlock.c:160     unlock_rm()
...more

Nested inline functions

inlinecall(1) resolves nested inline functions recursively:

$ ./inlinecall critical_enter /usr/lib/debug/boot/kernel/kernel.debug
/usr/src/sys/sys/systm.h:175
        [0xffffffff80a19d7a - 0xffffffff80a19d8b]       /usr/src/sys/sys/buf_ring.h:80  drbr_enqueue()
/usr/src/sys/sys/systm.h:175
        [0xffffffff80a6387a - 0xffffffff80a6388b]       /usr/src/sys/sys/buf_ring.h:80  drbr_enqueue()
...

Looking at the definition of critical_enter()’s caller function in buf_ring.h:

static __inline int
buf_ring_enqueue(struct buf_ring *br, void *buf)
{
	...
	critical_enter();
	...
}

Even though inlinecall(1) reported that critical_enter() is called from drbr_enqueue() in buf_ring.h:80, we see that it’s called from buf_ring_enqueue() instead, but buf_ring_enqueue() is also an inline function:

$ ./inlinecall buf_ring_enqueue /usr/lib/debug/boot/kernel/kernel.debug
/usr/src/sys/sys/buf_ring.h:63
        [0xffffffff80a19d7a - 0xffffffff80a19dcd]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
        [0xffffffff80a19ddc - 0xffffffff80a19e18]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
        [0xffffffff80a19e1f - 0xffffffff80a19e3b]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
/usr/src/sys/sys/buf_ring.h:63
        [0xffffffff80a6387a - 0xffffffff80a638cd]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
        [0xffffffff80a638dc - 0xffffffff80a63918]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
        [0xffffffff80a6391f - 0xffffffff80a6393b]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
/usr/src/sys/sys/buf_ring.h:63
        [0xffffffff80d1f81a - 0xffffffff80d1f879]       /usr/src/sys/net/ifq.c:57       drbr_enqueue()
        [0xffffffff80d1f91d - 0xffffffff80d1f964]       /usr/src/sys/net/ifq.c:57       drbr_enqueue()
        [0xffffffff80d1f9dd - 0xffffffff80d1f9f5]       /usr/src/sys/net/ifq.c:57       drbr_enqueue()
/usr/src/sys/sys/buf_ring.h:63
        [0xffffffff80ff07ba - 0xffffffff80ff080d]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
        [0xffffffff80ff081c - 0xffffffff80ff0858]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()
        [0xffffffff80ff085f - 0xffffffff80ff087b]       /usr/src/sys/net/ifq.h:337      drbr_enqueue()

Here drbr_enqueue() is defined twice — once in ifq.h and once in ifq.c. The definition in ifq.h is also an inline definition, and in ifq.c it’s a non-inline one. We know that buf_ring_enqueue() is called from the non-inline version of drbr_enqueue(), otherwise inlinecall(1) would have reported the function which calls the inline version of drbr_enqueue().

In defense of the Old Web

Wed, 17 Aug 2022 00:00:00 +1200

The internet has reached the point where almost everything has been concertrated in just a few platforms. This is both opposed to the original idea of a decentralized and free internet, and is also used as a tool for control, since the flow of information is “managed” only by a handful of companies. Another problem is the amount of AI-generated and SEO-optimized websites plaguing every search engine result nowadays, making it almost impossible to find quality handwritten individual websites anymore.

My rather romanticized proposal is that we should make an attempt return to the old ways of the internet (1990s-2000s) — when personal websites and small communities were thriving — not because of nostalgia, but because it espoused better values and promoted creativity, despite its problems (spam, malware, bad security practices, unencrypted traffic). This might very well be a pipe dream at this point, but I think it would be great to at least see the existing movement attracting more people than it already does.

I was initially working on a full article explaining my viewpoint in depth, but the following articles express them better than I could ever have:

So, how can you be part of the small web? To start off, you need:

A domain name.
Somewhere to host your website/service. I rent a Vultr VPS with the cheapest plan available, which is more than enough for my needs, but you can even do self-hosting at home if you want. If you do rent from Vultr, you can follow this guide.
To connect the domain name with the server, so that your website can be reached.
A stable and secure operating system for servers, such as FreeBSD or OpenBSD.

A list of guides I’ve written:

To make finding other websites easier, have a links page, and consider being part of a Webring.

The tools you choose to manage your website depend on personal preference and needs, but I firmly believe that because building a website is not rocket science, and because the web has been getting severely bloated you don’t need anything more than a few command line utilities, a text editor, and perhaps a static site generator. Modern web frameworks tend to cause more headaches than actually improve workflow, so I’ll refrain from recommending them. I like writing articles in Markdown, and using Hugo for static site generation and templating.

Making a character device kernel module on FreeBSD

Sun, 10 Jul 2022 00:00:00 +1200

This article assumes advanced knowledge of C and a basic understanding of the FreeBSD kernel and programming environment. It is also meant to serve as a template/reference and not a complete implementation.

Sample code can be found here.

Also mirrored on the FreeBSD Wiki.

Implementing the device

malloc declaration

Kernel modules have their own malloc types, which are defined as follows:

MALLOC_DECLARE(M_MYDEV);
MALLOC_DEFINE(M_MYDEV, "mydev", "device description");

Then, you can use malloc(9) and free(9) as:

p = malloc(sizeof(foo), M_MYDEV, M_WAITOK | M_ZERO);
free(p, M_MYDEV);

`cdevsw` structure

The device’s properties and methods are stored in a cdevsw (Character Device Switch) structure, defined in sys/conf.h. The fields we care about most of the time are the following:

struct cdevsw {
	int			d_version;
	u_int			d_flags;
	const char		*d_name;
	d_open_t		*d_open;
	d_fdopen_t		*d_fdopen;
	d_close_t		*d_close;
	d_read_t		*d_read;
	d_write_t		*d_write;
	d_ioctl_t		*d_ioctl;
	d_poll_t		*d_poll;
	d_mmap_t		*d_mmap;
	d_strategy_t		*d_strategy;
	dumper_t		*d_dump;
	d_kqfilter_t		*d_kqfilter;
	d_purge_t		*d_purge;
	d_mmap_single_t		*d_mmap_single;
	...
};

All the *_t pointers are pointers to functions meant to be implemented by the driver. Not all functions have to be implemented however, but we usually do need to implement open(), close(), read(), write() and ioctl().

Declare the functions using some handy typedefs:

static d_open_t		mydev_open;
static d_close_t	mydev_close;
static d_read_t		mydev_read;
static d_write_t	mydev_write;
static d_ioctl_t	mydev_ioctl;

Declare the cdevsw structure:

static struct cdevsw mydev_cdevsw = {
	.d_name     = "mydev",
	.d_version  = D_VERSION,
	.d_flags    = D_TRACKCLOSE,
	.d_open     = mydev_open,
	.d_close    = mydev_close,
	.d_read     = mydev_read,
	.d_write    = mydev_write,
	.d_ioctl    = mydev_ioctl,
};

The D_TRACKCLOSE flag tells the kernel to track when the device closes so that it can close normally in case something goes wrong.

open() and close()

Those two functions are mainly used for resource allocation/deallocation and environment preparation:

static int
mydev_open(struct cdev *dev, int flags, int devtype, struct thread *td)
{
	int error = 0;

	/* do stuff */

	return (error);
}

static int
mydev_close(struct cdev *dev, int flags, int devtype, struct thread *td)
{
	int error = 0;

	/* do stuff */

	return (error);
}

read() and write()

It’s good practice to keep an internal buffer. Below is a very simplified example. The buffer in this example is allocated and deallocated on module load and unload respectively:

#define BUFSIZE (1 << 16)

struct foo {
	char	buf[BUFSIZE + 1];
	size_t	len;
};

static struct foo *foo;

Data to be received or sent back is stored in uio and the copy from user to kernel memory is done through uiomove(9), defined in sys/uio.h:

static int
mydev_read(struct cdev *dev, struct uio *uio, int ioflag)
{
	size_t amnt;
	int v, error = 0;

	/*
	 * Determine how many bytes we have to read. We'll either read the
	 * remaining bytes (uio->uio_resid) or the number of bytes requested by
	 * the caller.
	 */
	v = uio->uio_offset >= foo->len + 1 ? 0 : foo->len + 1 - uio->uio_offset;
	amnt = MIN(uio->uio_resid, v);

	/* Move the bytes from foo->buf to uio. */
	if ((error = uiomove(foo->buf, amnt, uio)) != 0) {
		/* error handling */
	}

	/* do stuff */

	return (error);
}

static int
mydev_write(struct cdev *dev, struct uio *uio, int ioflag)
{
	size_t amnt;
	int error = 0;

	/* Do not allow random access. */
	if (uio->uio_offset != 0 && (uio->uio_offset != foo->len))
		return (EINVAL);

	/* We're not appending, reset length. */
	else if (uio->uio_offset == 0)
		foo->len = 0;

	amnt = MIN(uio->uio_resid, (BUFSIZE - foo->len));
	if ((error = uiomove(foo->buf + uio->uio_offset, amnt, uio)) != 0) {
		/* error handling */
	}

	foo->len = uio->uio_offset;
	foo->buf[foo->len] = '\0';

	/* do stuff */

	return (error);
}

ioctl()

To create an ioctl, you give it a name and #define it using one of the following _IO* macros defined in sys/ioccom.h:

_IO: No parameters.
_IOR: Copy out parameters. Read from device.
_IOW: Copy in paramters. Write to device.
_IOWR: Copy parameters in and out. Write to device and read the modified data back.

Each of those macros* takes 3 arguments:

An arbitrary one-byte “class” identifier.
A unique ID.
The parameter type (can be anything), which is used to calculate the parameter’s size. The macro expands the type to sizeof(type).

* _IO takes only the first 2 arguments (class and ID) since it doesn’t use parameters.

We can now define a few ioctls that take foo_t as a parameter. This is usually done in a separate header file so that programs can use the ioctls:

#include <sys/ioccom.h>

typedef struct {
	int x;
	int y;
} foo_t;

#define MYDEVIOC_READ	_IOR('a', 1, foo_t)
#define MYDEVIOC_WRITE	_IOW('a', 2, foo_t)
#define MYDEVIOC_RDWR	_IOWR('a', 3, foo_t)

mydev_ioctl() is responsible for handling the ioctls we declared:

static int
mydev_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags,
    struct thread *td)
{
	foo_t *fp;
	int error = 0;

	switch (cmd) {
	case MYDEVIOC_READ:
		fp = (foo_t *)addr;
		/* do stuff */
		break;
	case MYDEVIOC_WRITE:
		fp = (foo_t *)addr;
		/* do stuff */
		break;
	case MYDEVIOC_RDWR:
		fp = (foo_t *)addr;
		/* do stuff */
		break;
	default:
		error = ENOTTY;
		break;
	}

	return (error);
}

Creating and destroying the device

Character devices are given a struct cdev handle upon creation, which we usually store as a global variable:

static struct cdev *mydev_cdev;

Devices are created with the make_dev() function, which is defined as:

struct cdev *
make_dev(struct cdevsw *cdevsw, int unit, uid_t uid, gid_t gid, int perms,
    const char *fmt, ...);

sys/conf.h has the definitions of all available flags.

Create the device:

mydev_cdev = make_dev(&mydev_cdevsw, 0, UID_ROOT, GID_WHEEL, 0666, "mydev");

When done, destroy the device:

destroy_dev(mydev_cdev);

Module declaration

Necessary includes:

#include <sys/types.h>
#include <sys/param.h>
#include <sys/conf.h>
#include <sys/systm.h>
#include <sys/kernel.h>
#include <sys/module.h>
#include <sys/malloc.h>
#include <sys/uio.h>

Implement the module’s event handler. This function is called at module load and unload. Since we’re dealing with a character device, it makes sense to create the device upon load and destroy it upon unload:

static int
mydev_modevent(module_t mod, int type, void *arg)
{
	int error = 0;

	switch (type) {
	case MOD_LOAD:
		mydev_cdev = make_dev(&mydev_cdevsw, 0, UID_ROOT, GID_WHEEL,
		    0666, "mydev");
		foo = malloc(sizeof(foo_t), M_MYDEV, M_WAITOK | M_ZERO);
		foo->buf[0] = '\0';
		foo->len = 0;
		break;
	case MOD_UNLOAD: /* FALLTHROUGH */
	case MOD_SHUTDOWN:
		free(foo, M_MYDEV);
		destroy_dev(mydev_cdev);
		break;
	default:
		error = EOPNOTSUPP;
		break;
	}

	return (error);
}

Lastly, declare the module. The first argument is the module’s name, the second one is a pointer to the event handler and the last one is any data we want to supply the event handler with, i.e., the arg argument in mydev_modevent():

DEV_MODULE(mydev, mydev_modevent, NULL);

Makefile

KMOD=   mydev
SRCS=   mydev.c

.include <bsd.kmod.mk>

Running the module

$ make
# kldload ./mydev.ko
...
# kldunload ./mydev.ko
$ make clean cleandepend

Testing

To test the module, load it, and create a simple program that opens the device, and makes a few calls to ioctl(2), read(2) and write(2).

RSS: Advantages and usage

Fri, 27 May 2022 00:00:00 +1200

RSS (Really Simple Syndication) is a standardized protocol for creating and sharing web feeds. An RSS feed is an XML file consisting of entries, each of them usually corresponding to an article. Programs called “RSS aggregators”, parse these files and provide a nice display where you can nagivate through each entry as if it were a news feed. This is a very convenient way to “follow” websites because all you have to do is grab their RSS URL, add it to your aggregator, and read the articles once it parses the feed.

On the website owner’s end, a new entry needs to be added whenever a new article is published. The entry usually includes a short summary of the article, or as is the case for my website, the whole article, so that you can read it all through your RSS reader.

Why bother

RSS is an open protocol, it’s decentralized, and very simple both in terms of parsing and maintaining. Because RSS is such a simple protocol, it can adapt to everyone’s workflow. There are RSS readers for Android, Windows, UNIX, web browsers, email clients, etc.

Apart from the technical advantages RSS provides, it’s also a great way to have a personal, uncensored feed, following only the websites you want — even YouTube channels — without ads and additional noise and distractions.

I personally use sfeed as an RSS reader, because I like the extensibility it offers. I’ve written a small patch for sfeed_curses(1), so that you can bookmark feed entry URLs to a predefined file. I use this mostly to queue videos and podcasts and then stream them through mpv using a very simple script I created, which, all it does is read the “queue” file and pipe the URLs to mpv.

How to create and maintain an RSS feed

Below is a very basic RSS feed. Inside the <channel> tags is the whole feed, and inside <item> is each individual entry. The rest of the tags are pretty self-explanatory, if not, feel free to read the specification. The article/summary is placed inside <description> — that can be in plain text or encoded HTML:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>

<title>Example Org</title>
<description>Example Org's RSS feed</description>
<link>http://www.example.org/rss.xml</link>

<item>
<title>Example entry</title>
<link>http://www.example.org/blog/post.html</link>
<pubDate>Sun, 06 Sep 2009 16:20:00 +0000</pubDate>
<description>
Here is some text containing an interesting description.
</description>
</item>

</channel>
</rss>

To create a new entry, you can either handwrite it in the XML file yourself, make a script or small program to do it automatically, or use some existing tool.

To share the feed, simply add the URL to your website and tell people to subscribe to it. For example, my website’s RSS feed can be obtained from https://margiolis.net/w/rss.xml.

RSS for some popular platforms

YouTube

Go to the channel’s home page, right-click and click on “Page source” and search for channelId" content. Copy the hash inside content="" and append it to the following URL (replace FILLME):

https://www.youtube.com/feeds/videos.xml?channel_id=FILLME

You can easily fetch YouTube RSS URLs here.

GitHub

You can get an RSS feed for each new commit that happens in a given branch. Replace username, repo and branch with the correct values:

https://github.com/username/repo/commits/branch.atom

Quit social media.

News

Avoid the news.

Share ZFS datasets with NFS

Sat, 21 May 2022 00:00:00 +1200

Thanks to Mark Johnston <markj@FreeBSD.org> for recommending this configuration. The article is also mirrored on the FreeBSD Wiki.

Host

Add the following lines to /etc/rc.conf:

nfs_server_enable="YES"
mountd_enable="YES"
mountd_flags="-n"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
rpcbind_enable="YES"

For some reason the NFS server needs to be restarted the first time after boot. A simple way to do this automatically is:

# echo "service nfsd restart" >> /etc/rc.local

Set the sharenfs property to the dataset you want to share. Replace the IPs and pool/dataset* with your desired values. ZFS properties are documented in zfsprops(8).

We’re going to share 2 datasets, one with read-write and one with read-only access:

# chmod -R 777 /pool/dataset_rw
# zfs set sharenfs="-alldirs,-network=192.168.1.0/24" pool/dataset_rw
# zfs set sharenfs="-ro,-alldirs,-network=192.168.1.0/24" pool/dataset_ro

Start the NFS server:

# service nfsd start
# service mountd reload

Guest

Acquire the host’s IP address using ifconfig(8) on it first. We’ll assume it’s 192.168.1.5.

Mount the filesystems. /pool/dataset* corresponds to the actual mount point of the dataset in the host:

# mkdir -p /mnt/dataset_rw /mnt/dataset_ro
# mount -t nfs -o rw 192.168.1.5:/pool/dataset_rw /mnt/dataset_rw
# mount -t nfs -o ro 192.168.1.5:/pool/dataset_ro /mnt/dataset_ro

When done, unmount:

# umount /mnt/dataset_rw /mnt/dataset_ro

In case you want the filesystems to be mounted on boot, add the following lines to /etc/fstab:

192.168.1.5:/dataset_rw   /mnt/dataset_rw	nfs     rw      0       0
192.168.1.5:/dataset_ro   /mnt/dataset_ro	nfs     ro      0       0

Process queuing using lock files

Wed, 18 May 2022 00:00:00 +1200

Locking will be done using the fcntl(2) system call. I’m aware of lockf(3) and flock(2), but both of them normally use fcntl(2) under the hood, and they are not as portable.

For a real use-case, I’ve written a notification program which uses the same mechanism, so that notifications can be queued without having to run a daemon, such as D-Bus, in the background.

First create the lock file with write permissions. O_CREAT is used to create the file in case it doesn’t exist already:

#include <err.h>
#include <fcntl.h>
...
char *lockfile = "/tmp/foo.lock";
int fd;

if ((fd = open(lockfile, O_CREAT | O_WRONLY, 0600)) < 0)
	err(1, "open(%s)", lockfile);

Locking commands operate on the flock structure. Before a call to fcntl(2) is made, we need to write the following fields:

struct flock {
	off_t	l_start;	/* starting offset */
	off_t	l_len;		/* len = 0 means until end of file */
	short	l_type;		/* lock type: read/write, etc. */
	short	l_whence;	/* type of l_start */
	...
};

The starting offset, l_len, can be anything, but 0 is what makes the most sense. We’ll set l_len to 0 as well, since we want each process to lock the entire file. The lock type, l_type, needs to be an exclusive lock (F_WRLCK), that is, a lock that prevents any other process from setting a lock on that area before it’s released. l_whence will be set to SEET_SET to indicate that the relative offset l_start will be measured from the beginning of the file:

struct flock fl;

fl.l_len = 0;
fl.l_start = 0;
fl.l_type = F_WRLCK;
fl.l_whence = SEEK_SET;

The F_SETLKW command will make the calling process wait until the lock request can be satisfied. There’s also F_SETLK, but it returns immidiately if the lock is already acquired, which is not very useful for queuing processes:

if (fcntl(fd, F_SETLKW, &fl) < 0)
	err(1, "fcntl(F_SETLKW)");

When we get past the call to fcntl(2), it means that we have acquired the lock until a call to close(2) is made. Here is where we’ll put the part of the code we want to queue, in this case a simple printf followed by a 3-second sleep to make sure queuing really works:

printf("hello from %d\n", getpid());
sleep(3);

When done, release the lock:

close(fd);

To test the code, open two terminals and run the program on both of them. You’ll see the process that was run last will not execute the code after fcntl(2) until the first one has finished.

FreeBSD VNET Jails

Sat, 30 Apr 2022 00:00:00 +1200

This article is also mirrored on the FreeBSD Wiki.

Configuration

The VNET is set up using an if_epair(4) interface bridged with the actual network interface, in my case re0. Just like if_tap(4) interfaces, epairs can be used by one jail at a time, so if you need to run more than one jail at the same time, you have to make more epairs.

If you’re using tap interfaces for bhyve VMs, you can just addm them to the bridge.

Add the following lines to /etc/rc.conf:

if_bridge_load="YES"
if_epair_load="YES"

cloned_interfaces="bridge0"
ifconfig_bridge0="addm re0 up"

Apply changes:

# /etc/netstart

The jail needs to inherit /dev/bpf* from the host in order for networking to work at all. Make a new /etc/devfs.rules ruleset:

[devfsrules_jails=5]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'bpf*' unhide

Restart devfs(8):

# service devfs restart

In /etc/jail.conf, we’ll name the jail foo and give it the other end of the epair we’ll create as its network interface. Its IP address will be acquired using DHCP. The reason I’m manually calling dhclient(8) is because adding ifconfig_epair0b="DHCP" in the jail’s /etc/rc.conf doesn’t work. Options are detailed in jail.conf(5):

path = "/usr/local/jail/$name";
host.hostname="$name";

exec.clean;
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
allow.mount;
allow.raw_sockets = 1;
mount.devfs;
devfs_ruleset="5";
vnet;
sysvmsg=new;
sysvsem=new;
sysvshm=new;

foo {
	vnet.interface = "epair0b";
	exec.start += "dhclient epair0b";
}

Installation

# mkdir -p /usr/local/jail/foo
# bsdinstall jail /usr/local/jail/foo
...
# ifconfig epair0 create
# ifconfig bridge0 addm epair0a
# ifconfig epair0a up
# service jail onestart foo

Test to see if the jail has networking:

# jexec foo ping google.com

On jail shutdown, destroy the epair:

# service jail onestop foo
# ifconfig epair0a destroy

Delete jail

Deleting jails isn’t as straight forward, so I’m leaving this here as well:

# service jail onestop foo
# chflags -R noschg /usr/local/jail/foo
# rm -rf /usr/local/jail/foo

A minimal and daemonless notification program for X

Sat, 02 Apr 2022 00:00:00 +1200

Source code | Download 0.2 | Man page

Features

Very lightweight. ~250 lines of C.
Probably no dependencies, apart from the pre-installed X11 ones. Xlib, libXft and libXrandr.
Multiple notifications are queued using a lock file. This avoids the trouble of having a daemon (e.g D-Bus) constantly running in the background.
Non-blocking behavior, so that it can be used inside scripts easily.
Configuration is done by editing config.h and recompiling the source code, in a similar fashion to suckless utilities. No knowledge of C is required to edit the file. Compilation takes around 1 second.
Clicking on the notification window will make it disappear.

nfy works by piping text into it. Text cannot be passed as argument:

$ echo 'hello world' | nfy
$ nfy < foo.txt

If stdin is empty, it exits with an error:

$ nfy
nfy: stdin is empty

Install

First make sure all settings in config.mk are set according to your system’s configuration, then:

# make install clean

Notes

If you want to use nfy(1) with cron(8), make sure to export the X Display variable inside the script running nfy(1):

export DISPLAY=":0.0"

Alternatively, export the variable in the crontab file directly.

Send feedback and bugs to <christos@margiolis.net>.

Why reinvent the wheel

Fri, 25 Mar 2022 00:00:00 +1200

I’ve got a few reasons for “reinventing the wheel”, some personal and some practical:

I’m curious and want to know how things really work.
I like DIY from scratch projects.
Bottom-up learning is valuable.
There are things that are fundamentally flawed and need to be done again from scratch.
Existing tools don’t always match the criteria for your specific task and/or introduce too much complexity.
Because there’s already a way to do something, it doesn’t mean it’s the right way to do it.

Some of the greatest innovations have in fact been a reinvention of the wheel, because what already existed at the time wasn’t good enough. Imagine someone telling James Watt he shouldn’t waste his time reinventing the wheel. Improving what already exists means we have stable foundations and better tools to work with in the future. The wheel itself has been reinvented multiple times, hence why we don’t use Bronze Age wheels anymore.

A good example in the software world of why sometimes reinventing the wheel is a good idea is UNIX vs Windows. UNIX was written from scratch to replace Multics which had serious flaws, so they ended up with a new and clean system, built right from the bottom-up. They reinvented the wheel and made huge innovations in the process. Windows on the other hand, is built on top of MS-DOS which even at the time was a mess, so what Microsoft is left with is an OS which up to this day is overly complicated, because of fundamental design flaws that cannot be fixed unless they do away with the whole thing and start from scratch. Instead, they are coming up with half-assed solutions and add complexity to the system with each update.

Then there’s quality and efficiency. Writing your own tools means they can be tailored to perform a specific task perfectly — something a big generalized framework or piece of software can’t do in many cases. We tend to ignore the improvements better software can bring in the long term and instead spend time fighting with not-so-great tools and also rely on the power of modern hardware to cope for our mediocre solutions (see modern web tools or the web in general).

So, am I proposing that we’d be better off writing machine code and building our own programs for everything? Absolutely not. What I AM saying though, is that instead of being allergic to reinventing the wheel, we can start to see the merits in it, without overdoing it. This approach is benefecial to our personal improvement as engineers, which means an improvement in software as a whole. Just as you learn any other skill by mastering and understanding the basics, programming has to be understood from the bottom-up, not the opposite way. There’s no point in knowing all kinds of fancy frameworks if all you see are black boxes, or cannot even implement a linked list if asked to. After all, it’s a fact that software is getting worse.

And to save myself from sounding ignorant, there are cases where reinventing the wheel is a problem, namely:

Companies rolling their own proprietary solutions for everything, and ending up creating protocols and programs, which are arguably worse, expensive, harder to maintain, and incompatible with existing software.
People who like to reinvent the wheel for the sake of just having “their own” version of something, even when there actually is good software out there that covers their needs just as well.

Knowing how things really work will enable you to trace bugs easier, write/design more performant software, and overall know what the hell you’re doing. And that can only be achieved by, sometimes, reinventing the wheel. Nothing can teach you what getting your hands dirty will.

A related article I found funny.

Git on 9front

Sun, 13 Mar 2022 00:00:00 +1200

This article is also mirrored on the 9front Wiki.

Resources

User configuration

; mkdir $home/lib/git
; cat > $home/lib/git/config
[user]
	name=Your Name
	email=me@example.org
^D

Examples

Create, commit and push a repo:

; cd repo
; git/init
# add a remote in .git/config...
; git/add .
; git/commit -m 'commitmsg' foo.c
heads/front: 817a3f121083091291c45f1ddfcd1b042343efab
; git/push

Clone and push changes to a repo:

; git/clone git://git.example.org/repo
; cd repo
# make changes...
; git/commit foo.c
; git/push

Make a patch:

# make changes...
; git/commit -m 'commitmsg' foo.c
heads/front: 817a3f121083091291c45f1ddfcd1b042343efab
; git/export > patch.diff

Apply a patch:

; git/import < patch.diff
applying commitmsg

See which files have changed:

; git/diff -s
M foo.c
M bar.c

Shithub usage

First ask Ori (ori AT eigenstate DOT org) for a user.

Create and push a repository:

; rcpu -u $user -h shithub.us -c \
	newrepo -d 'description' -c 'me@example.org' reponame
; git/push -u hjgit://shithub.us/$user/reponame

Repositories live under /usr/git/$user. Each repo contains editable files in /usr/git/$user/repo/.git:

webpublish: If this file exists, then the repository is published in the public web list of repositories.
desc, description: The short description of the repository. It shows up in the repo list.
contact: Contact information for submitting patches. Shows up on the repository info page.

9front CPU server setup

Mon, 07 Mar 2022 00:00:00 +1200

The contents of /net/ndb will be useful throughout the whole process; have them visible in another window:

; ip/ipconfig
; cat /net/ndb
ip=192.168.1.152 ipmask=255.255.255.0 ipgw=192.168.1.3
	sys=cirno
	dns=192.168.1.1
	dns=192.168.1.1

Boot settings

The 9fat partition contains the kernel, bootloader and boot settings. Add the following lines to plan9.ini. Make sure the values match your own configuration:

; 9fs 9fat
; cd /n/9fat
; cat >> plan9.ini

user=glenda
cpu=192.168.1.152
auth=192.168.1.152
authdom=someauth
service=cpu
^D

user is kind of like the root user on UNIX systems, cpu and auth define the IP addresses for the CPU and auth server respectively, authdom is the domain name of our the server, and service=cpu starts the CPU listener at boot time.

9front needs to boot hands-free, so the bootargs prompt has to be skipped. To do that, change the bootargs variable (its values might be different) in plan9.ini:

bootargs=local!/dev/sdE0/fs
# change to...
noobootprompt=local!/dev/sdE0/fs -m 291 -A -a tcp!*!564

Auth server

Set up the auth server hostowner’s name and password; authid and authdom have to match the values in plan9.ini:

; auth/wrkey
bad nvram des key
bad authentication id
bad authentication domain
authid: glenda
authdom: someauth
secstore key:
password: <your_pass>

Add glenda’s password. This has to be the same as the one you typed in wrkey(8). Always run keyfs(4) before modifying keys:

; auth/keyfs
; auth/changeuser glenda
Password: <your_pass>
Confirm password: <your_pass>
assign new Inferno/POP secret? [y/n]: y
make it the same as Plan 9 password? [y/n]: y
Expiration date (YYYYMMDD or never)[never]:
Post id:
User's full name: 
Department #:
User's email address:
user glenda installed for Plan 9

; auth/enable glenda

Network database

Add the following lines to /lib/ndb/local (pay close attention to detail, especially ip=):

; cat >> /lib/ndb/local

authdom=someauth auth=192.168.1.152

ipnet=iphome ip=192.168.1.0 ipmask=255.255.255.0
	ipgw=192.168.1.3
	auth=192.168.1.152
	authdom=someauth
	fs=192.168.1.152
	cpu=192.168.1.152
	dns=192.168.1.1
^D

ipnet can be anything.

Sync the changes and reboot the system:

; echo sync >> /srv/hjfs.cmd
; fshalt -r

On reboot

Enable networking:

; bind -a '#l0' /net
; ip/ipconfig
; ip/ipconfig ether /net/ether0

Drawterm as glenda:

$ drawterm -u glenda
cpu[cpu]: 192.168.1.152
auth[192.168.1.152]:
glenda@someauth dp9ik password: <your_pass>

Start a rio(1) instance:

cpu% rio -s -i riostart

/cfg/$sysname/cpustart contains commands that run on boot. You can put whatever you want in it — I’m going to just add the same commands I ran after we rebooted to make my life easier.

; mkdir /cfg/$sysname
; cat > /cfg/$sysname/cpustart
bind -a '#l0' /net
ip/ipconfig
ip/ipconfig ether /net/ether0
cat /net/ndb
^D

New user

Add the new user to the file server, add it to some standard groups and assign it a password:

; echo newuser christos >> /srv/hjfs.cmd
; echo newuser sys +christos >> /srv/hjfs.cmd
; echo newuser adm +christos >> /srv/hjfs.cmd
; echo newuser upas +christos >> /srv/hjfs.cmd
; echo newuser cron +christos >> /srv/hjfs.cmd
; auth/keyfs
; auth/changeuser christos
...
; auth/enable christos

Let the new user “speak for” for other users by adding the following lines to /lib/ndb/auth:

; cat >> /lib/ndb/auth
hostid=christos
	uid=!sys uid=!adm uid=*
^D

Reboot for the changes to take effect:

; fshalt -r

Drawterm as christos and run newuser(8) to set up his home directory:

$ drawterm -u christos
...
; /sys/lib/newuser

Acme editor notes

Sun, 06 Mar 2022 00:00:00 +1200

Resources

The Acme User Interface for Programmers
A Tour of the Acme Editor - Watch this if you’re completely new.
Plan9 Acme Intro - Part 1
The Tao of Acme
Extensibility in the Acme text editor

Mouse

Acme needs a 3-button mouse to work properly. All buttons can be used to select text, but their function is different upon release. The left button is used for just selecting text. The middle button is used for executing text. The right button is for searching text and loading files or directories. Text doesn’t have to first be selected when using button 2 and 3 (middle and right) if the selection is only one word.

Acme also makes use of mouse chording (e.g pressing more than one button).


Button 1-2	Cut.
Button 1-3	Paste
Select text + Button 2-1	Execute with selection as argument.

Move around


`:2`	Go to 2nd line.
`:0`	Go to beginning of file.
`:$`	Go to end of file.
`CTRL-A`	Go to beginning of line.
`CTRL-E`	Go to end of line.
`CTRL-F`	Filepath autocompletion.
`Edit =`	Find current line number.

Search and select


`:,`	Select all lines.
`Edit ,`	Select all lines.
`:1,5`	Select lines 1 to 5.
`Edit 1,5`	Select lines 1 to 5.
`:/regexp/`	Select lines matching `regexp`.
`:/regexp1/,/regexp2/`	Select lines between `regexp1` and `regexp2`.
`Edit + /foo`	Forward serach.
`:/foo`	Forward search.
`:foo`	Forward search.
Right click kon word.	Forward search.
`Edit -/foo`	Backward search.
`:-/foo`	Backward search.
`-/foo`	Backward search.

Edit text


`CTRL-U`	Delete from cursor to beginning of line.
`CTRL-W`	Delete before cursor.
`CTRL-H`	Delete character before cursor.
`Edit , d`	Clear window.
`Edit , s/foo/bar/g`	Global replace.
`Edit , \| sed 's/foo/bar/g'`	Global replace.
`Edit s/foo/bar/g`	Replace in selection.
`Edit 2 d`	Delete 2nd line.
`Edit 2 c/foo`	Change 2nd line.
`Edit 2 a/foo`	Append after 2nd line.
`Edit 2 i/foo`	Prepend before 2nd line.

Work with external commands


`cmd`	Run `cmd` with the file as argument.
`\|cmd`	Pipe selection through `cmd` and also apply changes.
`>cmd`	Send selection to `cmd` and see result in a temporary window.
`<cmd`	Paste output of `cmd` in current window (no selection required).

Any command can be used, these are just a few examples.


`Edit , < echo foo`	Replace window body with some text (works with any command).
`echo foo \| 9p write acme/$winid/body`	Append to end of current window body.
`Edit , > wc -l`	Count lines.
`Edit , \| sort`	Sort lines.
`Edit ,x/regexp/ < date`	Replace `regexp` with the output of date(1).
Select text + `\| sed '' > foo.txt`	Cut to `foo.txt`.
Select text + `> sed '' > foo.txt`	Copy to `foo.txt`.

Files

As mentioned earlier, files are opened using the right mouse click.


`foo.c`	Open file.
`foo.c:3`	Open file on line 3.
`foo.c:3:9`	Open file on line 3 column 9.
`foo.c:/^func`	Open file on the line starting with `func`.
`foo.c:/bar/,/baz/`	Open file with a selection from `bar` to `baz`.

Useful Acme commands


`win`	Spawn shell as a window.
`web URL`	Open `URL` in browser.
`Dump`	Save current state.
`Load`	Load dump.
`Tab 8`	Set tab width to 8.

Variables


`$%`	Current file name.
`$samfile`	Current file name.
`$winid`	Current window.

FreeBSD sound mixer improvements

Fri, 25 Feb 2022 00:00:00 +1200

This project was part of Google Summer of Code 2021. The development report can be found on the FreeBSD Wiki. The reason behind this project is that the FreeBSD’s OSS mixer capabilities were really basic and outdated — even un/muting didn’t exist and one had to write custom scripts for such a basic task. Setting default audio devices had to be done by tweaking sysctls and programs needing to use the mixer required DIY implementations as there was no mixer library available. The project is part of FreeBSD 14.0.

Kernel patches

Un/muting (commit)

I decided that un/muting is better to be implemented in sound(4) in order to avoid having to write daemons or use files. The way this works is by implementing the SOUND_MIXER_READ_MUTE and SOUND_MIXER_WRITE_MUTE ioctls, which did exist in older OSS implementations, but were considered obselete. One thing to note is that the functionality isn’t the same as their old one. Older OSS versions had those 2 ioctls take/return an integer with a value of 0 or 1, which indicated whether the whole mixer is muted or not. My implementation takes/returns a bitmask that tells which devices are muted. This allows us to mute and unmute only the devices we want, instead of the whole mixer. If you’re familiar with the OSS API, this bitmask works the same way as DEVMASK, RECMASK and RECSRC.

Playback/recording mode information (commit)

Here I implemented a sysctl (dev.pcm.<N>.mode) which gives information about a device’s playback/recording mode. The rationale for this control is to include /dev/sndstat’s mixer information in the output of the new mixer(8). The sysctl can return the following values (NOTE: these values are OR’ed together if more than one mode is supported):

Value	Meaning
0x01	Mixer
0x02	Playback
0x04	Recording

Userland

mixer(3) implementation (commit)

mixer(3) provides a simple interface for working with the OSS mixer. The man page explains how the library works, including some examples, so there’s no need to repeat myself. You can see the library in action in the source code for mixer(8).

The basic structure of a program looks like this (link with -lmixer):

#include <err.h>
#include <mixer.h>

int
main(int argc, char *argv[])
{
	struct mixer *m;
	const char *name = "/dev/mixer0";

	if ((m = mixer_open(name)) == NULL)
		err(1, "mixer_open(%s)", name);

	/* do stuff */

	mixer_close(m);
	
	return (0);
}

mixer(8) rewrite (commit)

This implementation is a complete rewrite of the old mixer(8) utility. It now uses mixer(3) as a backend and implements all the new features the library provides. It’s got more command line options and works with a control-oriented interface inspired by OpenBSD’s mixerctl(8). Again, everything is detailed in the man page.

Old mixer(8) output:

$ mixer.old

Mixer vol      is currently set to  85:85
Mixer pcm      is currently set to 100:100
Mixer speaker  is currently set to  74:74
Mixer line     is currently set to   1:1
Mixer mic      is currently set to  67:67
Mixer mix      is currently set to  74:74
Mixer rec      is currently set to  37:37
Mixer igain    is currently set to   0:0
Mixer ogain    is currently set to 100:100
Mixer monitor  is currently set to  67:67
Recording source: mic

New mixer(8) output:

$ mixer

pcm0:mixer: <Realtek ALC662 rev3 (Analog 2.0+HP/2.0)> on hdaa0 kld snd_hda (play/rec) (default)
    vol       = 0.85:0.85     pbk
    pcm       = 1.00:1.00     pbk
    speaker   = 0.74:0.74     rec
    line      = 0.01:0.01     rec
    mic       = 0.67:0.67     rec src
    mix       = 0.74:0.74     rec
    rec       = 0.37:0.37     pbk
    igain     = 0.00:0.00     pbk
    ogain     = 1.00:1.00     pbk
    monitor   = 0.67:0.67     rec

Code and manuals

Thermometer using PIC16F877A and BME280

Mon, 14 Feb 2022 00:00:00 +1200

This embedded system measures temperature and humidity and outputs the data on an LCD. The BME280 sensor can also do pressure but I didn’t implement it because the MCU had no more space available. The whole project can be found here. I’ve also included datasheets for the MCU, sensor and LCD.

Development was done on FreeBSD using the workflow I describe here. If you’re using Microchip’s own tools, you’ll have to make some small changes to the code, but nothing too extreme.

The source code.

Components

Microchip PIC16F877A-I/P microcontroller.
Adafruit BME280 temperature, humidity and pressure sensor.
16x2 LCD.
1x 16MHz crystal oscillator.
2x 10kΩ resistor.
2x 300Ω resistor.
1x 10kΩ potentiometer.
2x 22pF ceramic capacitor.
2x LED.
2x push-button.
Breadboard and wires.
3x AAA batteries (4.5V total) or a 9V battery with a 5V voltage divider.

Safe temperature range

Component	Operating temperature
PIC16F877A	-40°C - 85°C
BME280	-40°C - 85°C
LCD	-20°C - 70°C

So, it’s best for the system to operate in the -20°C to 70°C range.

Schematic

You can also get the PDF version.

PIC microcontroller development on FreeBSD

Sun, 23 Jan 2022 00:00:00 +1200

Tested on FreeBSD 13.0. This article has also been mirrored on the FreeBSD Wiki.

Prerequisites

sdcc is a C compiler for microprocessors. It says that PIC microprocessors are unmaintained, but I’ve found it to be pretty reliable so far (take this with a grain of salt, I’m no expert). The FreeBSD port is lang/sdcc.

Page 75 of the sdcc user manual lists the supported PIC devices. Header files can be found under /usr/local/share/sdcc.

For programming the MCU, I’ve found pk2cmd to work alright with PICKit2 (or Chinese clones), but there’s no port for FreeBSD anymore. The Makefile won’t install files properly, so we have some extra work to do afterwards:

$ git clone https://github.com/psmay/pk2cmd.git
$ cd pk2cmd/pk2cmd
# gmake freebsd install clean
# mv /usr/share/pk2/PK2DeviceFile.dat /usr/local/bin
# rm -rf /usr/share/pk2

Supported devices for pk2cmd are listed here.

Detecting and programming the MCU

Avoid using just the -P option to auto-detect the MCU, as the VPP the PICKit2 applies to the chip trying to detect it can damage the MCU. Instead, use the chip number beforehand as shown below. Also, use the -C option to check if the chip is blank.

If any of the following pk2cmd commands fail, make sure everything really is wired properly:

$ pk2cmd -P PIC16F877A -C
Device is blank

Operation Succeeded

Compile your source code. The target executable is the .hex file sdcc will output. Replace pic14 and 16f877a with the appropriate names for your device:

$ sdcc --use-non-free -mpic14 -p16f877a main.c

Erase the PIC (if it wasn’t already blank) and flash the new code. Again, use the appropriate names:

$ pk2cmd -P PIC16F877A -E
$ pk2cmd -P PIC16F877A -X -M -F main.hex

If all went well, you should get an output similar to this:

PICkit 2 Program Report
23-1-2022, 21:01:29
Device Type: PIC16F877A

Program Succeeded.

Operation Succeeded

Email-driven Git workflow

Sun, 16 Jan 2022 00:00:00 +1200

Basic Git configuration (in case you haven’t already done that):

$ git config --global user.email you@example.org
$ git config --global user.name "Your Name"

Git email configuration:

$ git config --global sendemail.smtpserver your_mail_server
$ git config --global sendemail.smtpuser you@example.org
$ git config --global sendemail.smtpserverport your_smtp_port
$ git config --global sendemail.smtpencryption your_encryption_type

Examples

Apply a patch (or simply make a commit) and send it to a mailing list:

$ git am < some_patch
$ git send-email --to=list@example.org HEAD^

Fix last commit and send it:

$ git commit -a --amend
$ git send-email --annotate -v2 HEAD^

Send 3 last commits (see Revision Selection for more info on the notation):

$ git send-email HEAD~3

Send the last commit to list@example.org and make the subject look like “[reponame][PATCH] commitmsg”. This is useful for sending patches to mailing lists or programmers with multiple projects:

$ git send-email --subject-prefix="${PWD##*/}][PATCH" \
	--to=list@example.org -1

Simple as that. None of that fork & pull request crap.

How to jump start your car

Wed, 12 Jan 2022 00:00:00 +1200

There are tons of articles and videos out there already, but all of them are too long or AI-generated.

Requirements: jumper cables and a live car. Order matters.

Turn off the live car’s engine and remove the key. Make sure the emergency brake is on and the transmission in neutral. Also make sure that your cables are always apart and away from your body.
Dead car: connect the positive (red) end of the cable to the battery’s positive terminal. The terminals are distinguished from their colors (red for positive and black for negative) and/or their sign (+ for positive, - for negative).
Live car: connect the other positive end of the cable to the battery’s positive terminal
Live car: connect the negative (black) end of the cable to the battery’s negative terminal.
Dead car: connect the other negative end of the cable to a ground, for example a bolt on your hood.
Keep the cables away from hot components, such as the radiator or the engine.
Start the live car and slightly rev up the engine every now and then. Do this for a few minutes.
Dead (now alive) car: disconnect the ground.
Live car: disconnect the negative terminal.
Live car: disconnect the positive terminal.
Dead car: disconnect the positive terminal.

DO NOT confuse the terminals or you will destroy your car’s computer system.

C coding style

Sat, 01 Jan 2022 00:00:00 +1200

First of all, I wanna wish all 0 readers of this website a happy new year! There’s no reason to write a whole article repeating what better articles have already covered, so here’s a list with proper C coding style guides:

9front using bhyve(8) on FreeBSD

Tue, 23 Nov 2021 00:00:00 +1200

This article is also mirrored on the FreeBSD Wiki. and 9front Wiki.

Required ports:

sysutils/bhyve-firmware
sysutils/uefi-edk2-bhyve
sysutils/uefi-edk2-bhyve-csm
net/tigervnc-viewer

Add the following lines to /etc/rc.conf. Replace re0 with your own network interface. It’s good practice to assign each VM a unique tap interface in case you need to run multiple VMs at the same time. For simplicity’s sake, this setup uses only one tap:

if_bridge_load="YES"
if_tap_load="YES"
cloned_interfaces="bridge0 tap0"
ifconfig_bridge0="DHCP addm re0 addm tap0"
ifconfig_bridge0_alias0="inet 10.0.0.1/24"

Reboot your machine and then grab a 9front ISO.

Make a directory where you’ll store everything 9front-related. I usually keep all my bhyve(8) VMs under a ZFS dataset:

$ cd /path/to/vms/
$ mkdir 9front
$ mv /path/to/9front_iso 9front.iso

Create an empty file to be used as the VM’s hard drive. 10G will be more than enough:

$ truncate -s 10G disk.img

Make a startup script. Feel free to tweak the variable values to match your own setup. Obviously, when you’re done installing 9front from the ISO, you’ll be running the script without the -s 3,... line:

$ cat 9front_start

#!/bin/sh

name="9front"
cpu="2"
mem="2G"
iso="9front.iso"
disk="disk.img"
tap="tap0"

ifconfig ${tap} up

bhyve -c ${cpu} -m ${mem} -wH \
	-s 0,hostbridge \
	-s 3,ahci-cd,${iso} \
	-s 4,ahci-hd,${disk} \
	-s 5,virtio-net,${tap} \
	-s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait \
	-s 30,xhci,tablet \
	-s 31,lpc \
	-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
	${name}

Make a shutdown script in order for bhyve(8) to shutdown properly:

$ cat 9front_stop

#!/bin/sh

name="9front"
tap="tap0"

ifconfig ${tap} down
bhyvectl --force-poweroff --vm=${name}
bhyvectl --destroy --vm=${name}

Make the scripts executable and start the VM:

$ chmod +x 9front_start 9front_stop
# ./9front_start; ./9front_stop

Run vncviewer(1) to connect to the VNC display:

$ vncviewer 0.0.0.0

When prompted for the monitor type during boot, choose xga.

Git Web frontend with stagit(1)

Fri, 05 Nov 2021 00:00:00 +1200

stagit(1) reads Git repositories and generates static pages for them with a predefined CSS stylesheet (I said stylesheet twice!), a website logo and a favicon.

Required:

Install stagit(1):

$ git clone git://git.codemadness.org/stagit
$ cd stagit
# doas make install clean

I like to have everything stagit(1)-related inside /var/www/htdocs/git.example.org along with the actual repositories, but you can choose any other directory.

Store the stylesheet, logo and favicon inside. You’ll find the stylesheet inside the stagit(1) repository you cloned earlier; it’s called style.css. For the logo and favicon, just make your own, but make sure they are in PNG format and have the same names as below.

# cp logo.png favicon.png style.css /var/www/htdocs/git.example.org

You can edit the stylesheet to your likings, but if you’re afraid that you’ll mess things up, play around with the colors only.

Here I created a repository named repo in /var/www/htdocs/git.example.org/repo.git. I will now make a directory to store the files that stagit(1) will produce. I like to give it the same name as the repository but without the .git extension:

# mkdir /var/www/htdocs/git.example.org/repo

Create symlinks for the stylesheet, logo and favicon inside the directory you just created:

$ cd /var/www/htdocs/git.example.org/repo
# ln -s ../style.css ../logo.png ../favicon.png .

Run stagit(1) and generate the static page for your repository. This has to be done inside the directory you just created since stagit(1) stores the files in the working directory. Make sure that you give it the .git directory (i.e., the actual repository):

# stagit ../repo.git

Go to the top-level Git directory and generate an index.html file which is your Git server’s homepage where all repositories will be listed. Again, you give it the actual repositories:

$ cd /var/www/htdocs/git.example.org
# stagit-index repo.git > index.html

I’ve made a simple script to automate the generation process:

#!/bin/sh

cd /var/www/htdocs/git.example.org
for dir in $(ls | grep "git"); do
	cd ${dir%.*} && stagit ../${dir} && cd .. && echo "updating ${dir}: ok"
done
stagit-index $(ls | grep "git") > index.html && echo "creating index.html. ok"

Fire up a browser and go to git.example.org and you should see everything. Success!

OpenBSD Git server setup

Wed, 10 Feb 2021 00:00:00 +1200

Git subdomain

It’s good to have your Git server under a subdomain, so that it looks like git.example.org. To do that, add a new CNAME record for the subdomain on your registrar. If you’re on Epik, don’t forget the trailing period after the domain name.

Host: git | Points to: example.org.

Setting up the Git server

Install git(1):

# pkg_add git

First create a git user and give it a password. If you don’t want the same hosts that exist in your current user’s authorized_keys to have access to the Git server, then add their keys manually in the git user’s .ssh/authorized_keys file. In my case, it’s just me who has access to the server, so I will not edit anything:

# adduser git
...
# cp -r $HOME/.ssh /home/git/
# chown -R git:git /home/git/.ssh

Try SSH’ing to the server as git from your local computer just to test if it works:

$ ssh git@example.org

If it worked, exit the session.

Set up a Git directory where all repositories will be stored at and cd into it:

# mkdir /var/www/htdocs/git.example.org
# chown -R git:git /var/www/htdocs/git.example.org
# cd /var/www/htdocs/git.example.org

Say I want to create a repository named repo. The structure your repositories should have is name.git, so in this case it’ll be repo.git. Create a bare repository inside it:

# mkdir repo.git
# git init --bare repo.git

Replace each text inside double quotes with what you want it to be:

# echo "John Doe" > repo.git/.git/owner
# echo "This is a repo" > repo.git/.git/description
# echo "git://git.example.org/repo.git" > repo.git/.git/url

To be able to interact with the Git server, the repository’s owner needs to be the git user you created earlier:

# chown -R git:git repo.git

Since sometimes the Git server by default might not be listening on port 9418 (the default Git port), which means that you’ll not be able to clone repositories from the Git server, you have to set up the daemon yourself using a massive Git command. You can (in fact, you should) also use Git over HTTPS or SSH, but for now I’ll be using the default Git protocol for cloning and SSH for pushing.

# git daemon \
	--base-path=/var/www/htdocs/git.example.org/ \
	--export-all \
	--enable=receive-pack \
	--reuseaddr \
	--informative-errors \
	--verbose \
	--detach

Pushing changes to the server

On your local machine, make a repository for repo (the repository you created earlier) and add a few files so that you have something to commit and push to the server:

$ mkdir repo && cd repo
$ touch foo bar
$ git init
$ git add .
$ git commit -m "initial commit"

In order to be able to push you have to edit .git/config. If you’ve used GitHub before, you might have noticed that when you want to push, you push to origin; for this server I’ll use home, but you can use whatever else you want, it doesn’t really matter.

Append the following block to your repository’s .git/config and of course replace the domain and repository names with your own ones:

[remote "home"]
	url = git@git.example.org:/var/www/htdocs/git.example.org/repo.git
	fetch = +refs/heads/*:refs/remotes/home/*

Push to the Git server:

$ git push home master

Try also cloning the repository to make sure that everything works:

$ git clone git://git.example.org/repo.git

If that step was successful too, great, you now have a working Git server. :-)

Create a Web frontend with stagit(1).

OpenBSD Web server setup

Tue, 09 Feb 2021 00:00:00 +1200

HTTPS

acme-client(1) lets us have HTTPS.

Create the certificate directories:

# mkdir -p -m 700 /etc/ssl/private
# mkdir -p -m 755 /var/www/acme

Edit /etc/acme-client.conf. Replace example.org with your domain.

authority letsencrypt {
	api url "https://acme-v02.api.letsencrypt.org/directory"
	account key "/etc/ssl/private/letsencrypt.key"
}

domain example.org {
	domain key "/etc/ssl/private/example.org.key"
	domain certificate "/etc/ssl/example.org.crt"
	domain full chain certificate "/etc/ssl/example.org.pem"
	sign with letsencrypt
}

httpd(8)

OpenBSD already ships with a web server: httpd(8). You need to specify the following things:

The domain name.
Which port/s the server will listen to.
Where the website’s root directory is.

Create the website’s root directory. It should normally reside under /var/www/htdocs.

# mkdir -p /var/www/htdocs/example.org

The following configuration will suffice for now. With it you have HTTP and HTTPS for your website and it redirects HTTP to HTTPS automatically. If you want to learn more or see what other options and settings are available, read httpd.conf(5)’s man page. Inside /etc/httpd.conf we’ll write the following:

server "example.org" {
	listen on * port 80
	root "/htdocs/example.org"
	location "/.well-known/acme-challenge/*" {
		root "/acme"
		request strip 2
	}
	#block return 301 "https://example.org$REQUEST_URI"
}

server "example.org" {
	listen on * tls port 443
	root "/htdocs/example.org"
	tls {
		certificate "/etc/ssl/example.org.pem"
		key "/etc/ssl/private/example.org.key"
	}
	location "/.well-known/acme-challenge/*" {
		root "/acme"
		request strip 2
	}
}

Generate the TLS certificates:

# acme-client -v example.org

Test to see if the configuration is correct:

# httpd -n

(Re)start the web server:

# rcctl restart httpd

Certificate renewal

TLS certificates expire after a few months so new certificates need to be generated when they expire. In order to avoid having to remember this and having to manually generate them, a cronjob will do it automatically:

# crontab -e

Append the following line:

0 0 * * * acme-client -v example.org && rcctl reload httpd

Use cases for goto

Tue, 19 Jan 2021 00:00:00 +1200

This article is for everyone, who, for some reason, thinks goto should be avoided at all costs.

Some use cases

The most important use case there is for goto is by far error handling when there are more than 1 points of failure. In this case, you might want to cleanup some resources while also skipping part of the code that should not be executed, without having to deal with flags, helper functions, and other methods that would make the code ugly, slower and error prone. Try rewriting the following snippet without a goto:

int
foo(int *bar, int *baz)
{
	if (!func1())
		goto fail;
	if (!func2())
		goto fail;
	if (!func3())
		goto fail;

	return 0;

fail:
	warn("foo failed");
	if (bar != NULL)
		free(bar);
	if (baz != NULL)
		free(baz);

	return -1
}

Another use case is breaking out of deeply nested code. Let’s say you’ve got 3 for loops and there’s a special case in which you really want to break out of all the loops at once. how do you do that? There are multiple ways you can go about doing so but one way would be to set a flag and check it on every nested level.

flag = 0;

for (i = 0; i < 10; i++) {
	for (j = 0; j < 10; j++) {
		for (k = 0; k < 10; k++) {
			...
			if (flag)
				break;
		}
		if (flag)
			break;
	}
	if (flag)
		break;
}

Another ugly hack you can use is something another colleague from university showed me, and something I would never use; when the flag is set, manually max out all the loop counters.

A pretty straight-forward solution would also be to put the loop into a function and use a return statement to break out of all the loops. That’s actually a good solution, and I’m aware of it, but I want to provide another solution, which is also quite faster than using a function since it avoids that additional function call.

An alternative, and in my opinion, better way of solving this problem would be by using a (don’t say it, don’t say it) goto:

flag = 0;

for (i = 0; i < 10; i++) {
	for (j = 0; j < 10; j++) {
		for (k = 0; k < 10; k++) {
			...
			if (flag)
				goto end;
		}
	}
}
end:
...

Who cares, anyway?

In the first use case, the code is much more readable and you avoid code duplication. In the second use case the goto solution actually does improve performance. The reason why is simple; we check for flag on every single loop, which means, that in case flag is never set, we’ll have done 10 * 10 * 10 = 1000 checks just to see if flag is set. And that’s just with 3 for loops going from 0 to 10 each; think how easily this can scale up if you just increase the iterations. The goto solution does only one check in the third loop, which means that, in the above scenario, where flag never gets set, we’ll have done only 10 checks - that’s 100 times faster than the other solution.

Using a function is almost just as fast as using a goto without a function, but not having to call a function is generally faster. Both solutions are great and totally valid, I just want to show an alternative one.

Final note

goto does have its place but it should be used carefuly; if you overuse it, your code will either become incomprehensible, or flat out broken. The use cases I showcased in this post are very common and sometimes the code can be vastly improved with just a simple goto if used correctly.

Sync files with rsync(1)

Sun, 22 Nov 2020 00:00:00 +1200

Connecting local machines

In order to connect two machines on the same network, they both need to know each other’s network IP address. To get your network IP address execute the following command on each of the local machines you want to connect:

$ ifconfig

In your running network interface’s section, ifconfig will output a line that looks like this:

inet 192.168.x.y

This is your network IP address which the other machine needs to know. Suppose you want to connect two local machines at home; we’ll call the first one host1 and the other host2. the ip address for host1 is 192.168.1.7 and for host2 it’s 192.168.1.8. add the following line on host1’s /etc/hosts so that it knows who host2 is. do the same for host2.

192.168.1.8 host2

After completing this step ping each other using both the IP and the hostname to make sure everything works:

$ ping 192.168.1.8 

ping 192.168.1.8 (192.168.1.8): 56 data bytes
64 bytes from 192.168.1.8: icmp_seq=0 ttl=64 time=36.931 ms
...

$ ping host2

ping host2 (192.168.1.8): 56 data bytes
64 bytes from 192.168.1.8: icmp_seq=0 ttl=64 time=74.056 ms
...

If you don’t already have an SSH key pair, generate one:

$ ssh-keygen

Copy the SSH public key over to the other machine:

$ eval $(ssh-agent -s)
$ ssh-add
$ ssh-copy-id user@host2

Repeat the same process for host2. to verify that the key was indeed copied over, look at ~/.ssh/authorized_keys.

Using rsync

You can think of rsync(1) as cp(1) with superpowers; in fact, you could even alias cp to rsync.

To just copy a file on your machine you can do exactly the same thing you would do with cp:

$ rsync foo bar/

Suppose we want to send that file to host2 (read the previous section):

$ rsync foo host2:

By default, rsync(1) assumes that the target user has the same name as yours. In case it’s different, you need to specify it:

$ rsync foo user@host2:

The file will be copied in the other machine’s home directory, if no other directory is specified. To send it to a specific path:

$ rsync foo user@host2:foo/

rsync(1) has a lot of options, but some of the most common ones, and the ones I use most of the time are the following:

-r: Copy directories recursively.
-u: Update only the files that have changed (incremental copy).
-v: Increase verbosity.
-a: Preserve permissions and metadata. does not preserve hard links.
-p: In case something goes wrong and the sync breaks, continue the sync from where it stopped.
--delete-after: Delete the old files after the transfer.

Note: when you want to transfer a directory, you must add a / after its name (e.g foo/), otherwise rsync(1) will skip it.

Sample usage

Suppose I want to update a website that is hosted on a remote server. I can make changes locally and just sync it with the server whenever I want using rsync. Let’s say the remote directory is located at /var/www/website:

$ rsync -purv --delete-after website/ user@server:/var/www/website

You can automate this process using a simple shell script. In this case though, you have to pass the absolute paths of the directories so that you can run the script from everywhere:

#!/bin/sh

src="/foo/bar/website/"
dst="user@server:/var/www/website"
rsync -purv --delete-after ${src} ${dst}

Arduino on FreeBSD

Wed, 28 Oct 2020 00:00:00 +1200

This article demonstrates how to develop for Arduino boards using only basic command line utilities, without having to use the Arduino IDE. The article has also been published on the FreeBSD Wiki.

Tested on FreeBSD 12.2 and above.

Prerequisites

Required ports:

devel/arduino-core
devel/arduino-bsd-mk
devel/avr-gcc
devel/avr-libc
devel/avrdude
comms/uarduno

With all the software installed, add the following line to /boot/loader.conf in case you want the Arduino kernel module to load automatically on boot. If you want to manually load the module whenever you need it, skip this step:

uarduno_load="YES"

Load the kernel module:

# kldload uarduno

Check your ~/.arduino/preferences.txt and see if the following lines exist (source):

serial.port=/dev/cuaU0
launcher=/usr/local/bin/firefox

Add your user to the dialer group:

# pw group mod dialer -m $USER

Connecting the board

Standard Arduino boards connect as /dev/cuaU0 and/or /dev/ttyU0 on FreeBSD. In case these serial ports don’t show up in /dev, you might need to press your board’s reset button. After you’ve plugged your board into a USB port, you should get the following output from dmesg(8). Although the output may vary, the important thing is that your board is connected and detected.

ugen1.5: <Arduino (www.arduino.cc) product 0x0043> at usbus1
uarduno0: <Arduino (www.arduino.cc) product 0x0043, class 2/0, rev 1.10/0.01, addr 5> on usbus1

If dmesg returned information about your board, you should also see cuaU0 and/or ttyU0 in /dev. In case your board is still not detected — considering it’s not a fake one, try using a different USB cable or reset it again and make sure you’ve followed the setup steps correctly.

The Makefile

The only thing you’re going to need in order to get started is just a Makefile that’ll be used to compile and upload your Arduino programs. Make a new directory for your Arduino project and a Makefile with the following lines:

ARDUINO_DIR=    /usr/local/arduino
ARDUINO_MK_DIR= /usr/local/arduino-bsd-mk
#ARDUINO_LIBS=	
AVRDUDE_PORT=   your_board_port
ARDUINO_BOARD=  your_board_name
SRCS=           your_source_files
TARGET=         your_program_name

include /usr/local/arduino-bsd-mk/bsd.arduino.mk

In my case my board is an Arduino Uno, so I’d have to set ARDUINO_BOARD to uno. You can see which other board types are available in /usr/local/arduino/hardware/arduino/avr/boards.txt. If you want to install new libraries, copy them over to /usr/local/arduino/hardware/arduino/avr/libraries/.

Avoid having source files named main.

Building and uploading a program

Write some Arduino code, and when you’re ready to compile and upload, run the following command:

# make install flash clean cleandepend

If all went well you should see the board executing the new code. If it doesn’t, try to see what errors the Makefile produced.

Monitoring

The Arduino IDE provides a serial monitor feature, but FreeBSD has a builtin monitoring utility which can be accessed directly from the terminal. Run this whenever you want to monitor your board and exit with ~! (use the appropriate port):

$ cu -l /dev/cuaU0

Using board types other than the Uno

As it’s mentioned above, we’re using the uarduno kernel module. Even though the module’s description is “FreeBSD Kernel Driver for the Arduino Uno USB interface”, you can, in fact, use different board types other than the Uno. According to uarduno’s website, you can modify /usr/ports/comms/uarduno/files/ids.txt to include more board types; the two fields are Vendor ID and Product ID. Read the comments inside the file for more information.

{ 0x2341, 0x0001 },  // Arduino UNO, vendor 2341H, product 0001H
{ 0x2341, 0x0042 },  // Arduino MEGA (rev 3), vendor 2341H, product 0042H
{ 0x2341, 0x0043 },  // Arduino UNO (rev 3), vendor 2341H, product 0043H
{ 0x2341, 0x0010 },  // Arduino MEGA 2560 R3, vendor 2341H, product 0010H 
{ 0x2341, 0x8037 },  // Arduino Micro

When you’re done, clean and re-build the port.

Known issues and their fixes

Even though you might have plugged your board to your machine, you might notice that there is no device appearing in /dev. Although there is no definite answer as to why this is happening, make sure that the USB cable is connected properly; on some boards, you have to hear a click sound.

When trying to use a new library, you might notice that your code doesn’t compile. A common issue is that you haven’t stored the library in the correct path. As mentioned, libraries are stored in /usr/local/arduino/hardware/arduino/avr/libraries/, so you have to move it there.

Simple Brainfuck interpreter in C

Wed, 02 Sep 2020 00:00:00 +1200

How Brainfuck works

There are only 8 symbols supported in Brainfuck:

Symbol	Function
>	Increase position of pointer.
<	Decrease position of pointer.
+	Increase value of pointer.
-	Decrease value of pointer.
[	Beginning of loop.
]	End of loop.
.	Output ASCII code of pointer.
,	Read a character and store its ASCII value in pointer.

It’s best to imagine Brainfuck programs as arrays of integers, which the pointer can manipulate. Let’s say this is our initial state:

{ 0, 0, 0, 0, 0, 0 }

We can assign values to each position in the array by moving the pointer around. Using the + and - symbols, we can increment or decrement by 1 each time. If we wanted to move the pointer two times to the right and increment the value there by 3, we would have a program that looks like this:

>>+++

The updated version of the array:

{ 0, 0, 3, 0, 0, 0 }

Following the same logic, we can assign specific values to each cell and make an actual program. If we wanted to print the letter “B” on the screen, which corresponds to the ASCII value 66, we could write the following program:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.

In order to avoid writing things like this we can use loops. The loop is executed as long as the value inside it is not 0. Essentially, it’s going to do the multiplication 10 x 6 = 66 and then print the value:

+++++ +++++		# add 10 to cell #0
[			# beginning of loop
	> +++ +++	# add 6 to cell #1
	< -		# subtract 1 from cell #0
]			# end of loop
			# value at cell 1 is now 66 (10 x 6 = 66)
> .			# go to cell 1 and print its value

Or, for compactness:

+++++++++++[>++++++<-]>.

You can learn more about how Brainfuck works here.

Building the interpreter

We’ll first read the Brainfuck source from stdin into a static size buffer. 50.000 bytes should be large enough to store any Brainfuck program, since I doubt anyone is mad enough to write actual programs in it:

#define BUFSIZE 50000
.
.
.
size_t len = 0;
char buf[BUFSIZE];

while (read(STDIN_FILENO, &buf[len], 1) > 0)
	len++;
buf[len] = '\0';

We’ll declare the rest of the needed variables:

int closed;		/* number of active loops */
int opened;		/* number of inactive loops */
int pos = 0;		/* position in the program */
unsigned short *pc;	/* program counter */
char *src;		/* source code */

One of the reasons we have a len variable is to allocate just enough memory for src. We’ll also empty the buffer because we now want to use it to store the values the Brainfuck program will produce:

if ((src = malloc(len)) == NULL) {
	perror("malloc");
	exit(1);
}
strcpy(src, buf);
memset(buf, 0, len);

We can now parse the source code symbol by symbol. pc will act as the “pointer”, moving back and forth in the array. Each symbol will have its own case inside the following switch statement:

for (pc = (unsigned short *)buf, pos = 0; pos < len; pos++) {
	switch (src[pos]) {
		...
	}
}

For the < and > symbols we simply move the pointer:

case '>':
	pc++;
	break;
case '<':
	pc--;
	break;

The + and - symbols in/decrement the value of the cell the pointer is currently at:

case '+':
	(*pc)++;
	break;
case '-':
	(*pc)--;
	break;

To implement the . and , symbols we’ll use the standard library’s putchar() and getchar() functions:

case '.':
	putchar(*pc);
	break;
case ',':
	*pc = getchar();
	break;

Now comes the last, but harder part, which is to implement loops. The logic behind my implementation is that instead of keeping track of every bracket to know where a loop starts and ends, the program keeps going through the source code and, using a counter, we know that a loop starts or ends when that counter is 0 and and an opposite bracket has been found. Also, in each iteration the pos variable changes accordingly so that we can imitate the looping behavior of Brainfuck.

These are the steps the program follows for each of the two symbols:

Beginning of loop: `[`

If the pointer’s value is 0, we have a new loop.
Count how many (if any) nested loops we encounter.
If we encouter a [, increment the opened variable.
If we encouter a ], decrement the opened variable.
Keep counting until there are no new active loops (i.e., opened is 0).

case '[':
if (!(*pc)) {
	for (opened = 0; pos++; pos < len; pos++) {
		if (src[pos] == ']' && !opened)
			break;
		else if (src[pos] == '[')
			opened++;
		else if (src[pos] == ']')
			opened--;
	}
}
break;

End of loop: `]`

If the pointer’s value is is not 0, we have an active loop.
Start going back and count how many (if any) nested loops there are.
If we encouter a ], increment the closed variable.
If we encouter a [, decrement the closed variable.
Keep counting until there are no active loops (i.e., closed is 0).

case ']':
if ((*pc)) {
	for (closed = 0; pos--; pos >= 0; pos--) {
		if (src[pos] == '[' && !closed)
			break;
		else if (src[pos] == ']')
			closed++;
		else if (src[pos] == '[')
			closed--;
	}
}
break;

Putting it all together

Below is the full program. You can also find it here.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define BUFSIZE 50000

int
main(int argc, char *argv[])
{
	size_t len = 0;
	int closed, opened, pos = 0;
	unsigned short *pc;
	char buf[BUFSIZE], *src;

	while (read(STDIN_FILENO, &buf[len], 1) > 0)
		len++;
	buf[len] = '\0';

	if ((src = malloc(len)) == NULL) {
		perror("malloc");
		exit(1);
	}
	strcpy(src, buf);
	memset(buf, 0, len);

	for (pc = (unsigned short *)buf; pos < len; pos++) {
		switch (src[pos]) {
		case '>':
			pc++;
			break;
		case '<':
			pc--;
			break;
		case '+':
			(*pc)++;
			break;
		case '-':
			(*pc)--;
			break;
		case '.':
			putchar(*pc);
			break;
		case ',':
			*pc = getchar();
			break;
		case '[':
			if (!(*pc)) {
				for (opened = 0, pos++; pos < len; pos++) {
					if (src[pos] == ']' && !opened)
						break;
					else if (src[pos] == '[')
						opened++;
					else if (src[pos] == ']')
						opened--;
				}
			}
			break;
		case ']':
			if (*pc) {
				for (closed = 0, pos--; pos >= 0; pos--) {
					if (src[pos] == '[' && !closed)
						break;
					else if (src[pos] == ']')
						closed++;
					else if (src[pos] == '[')
						closed--;
				}
			}
			break;
		}
	}
	free(src);

	return (0);
}

Christos Margiolis: technology

Configuring Gmail and Outlook365 on Neomutt

Gmail

Outlook365

Notes

PostgreSQL 15 and pgAdmin4 on FreeBSD

PostgreSQL

pgAdmin4

Upgrading pgAdmin4

Inline function tracing with the kinst DTrace provider

Table of Contents

Quick background

Usage

Inline function tracing

How it works

Syntactic transformations

Heuristic for calculating the entry and return offsets

Using DWARF to find call sites of inline functions

Table of contents

What is DWARF?

Inline functions in DWARF

Calculating call boundaries

The DIE has DW_AT_low_pc and DW_AT_high_pc

The DIE has DW_AT_ranges

Finding the caller function

inlinecall(1)

Nested inline functions

In defense of the Old Web

Making a character device kernel module on FreeBSD

Table of contents

Implementing the device

malloc declaration

cdevsw structure

open() and close()

read() and write()

ioctl()

Creating and destroying the device

Module declaration

Makefile

Running the module

Testing

RSS: Advantages and usage

Why bother

How to create and maintain an RSS feed

RSS for some popular platforms

YouTube

GitHub

Social media

News

Share ZFS datasets with NFS

Host

Guest

Further reading

Process queuing using lock files

FreeBSD VNET Jails

Configuration

Installation

Delete jail

Further reading

A minimal and daemonless notification program for X

Features

Install

Notes

Why reinvent the wheel

Git on 9front

Resources

User configuration

Examples

Shithub usage

9front CPU server setup

Boot settings

Auth server

Network database

On reboot

New user

Acme editor notes

Resources

Mouse

Move around

Search and select

Heuristic for calculating the `entry` and `return` offsets

The DIE has `DW_AT_low_pc` and `DW_AT_high_pc`

The DIE has `DW_AT_ranges`

`cdevsw` structure

Beginning of loop: `[`

End of loop: `]`