Boron (not vibecoded)

[wooden shuttle]

race condition maybe

or some tlb thing

[glass heart]

WHAAAAT

why isnt it exiting

OSExitThread(1)

is supposed TO EXIT!

[wild widget]

why would the dcache need to be cleaned after relocateself

[glass heart]

i believe that when it fetches data for the icache it loads it directly from memory

but i may be wrong

[wild widget]

yes but what does the icache have to do with anything

dynamic relocation doesn't modify any instructions

[glass heart]

no?

[wild widget]

at least not on ELF systems

[glass heart]

i see

[wild widget]

dynamic relocation usually only relocates things in the GOT

so that the text section doesn't need to be cow'd

and if the text section does need to be modified the (compile-time) linker will add DT_TEXTREL

if I were you I'd either not support that situation or only clean the dcache if the entry is present

[glass heart]

i see, so rn it should Just Work™️ on real hardware you say?

if nothing else is buggy

[wild widget]

yeah

[glass heart]

speaking of buggy

yeah sometimes shit just doesn't work

when it does it's glorious

SYSCALL: 80215870 - 28 c0112188 OSOutputDebugString
WARNING:  This session WILL NOT have a keyboard attached and will be uninteractable!
SYSCALL: 80215870 - 13 c01345b8 OSExitThread
MiNormalFault: Declaring access violation on VA 7ff59e80. No VAD and not in a pool area

*** STOP (CPU 0):  invalid page fault thread=80215070, ip=7fff9b3c, faultaddr=7ff59e80, faultmode=00000807, status=2

TODO: DbgPrintStackTrace

seemingly another thread's stack pages are being freed ??

[glass heart]

I know the cause of this issue

[glass heart]

okay, I've fixed it

basically I wasn't saving and restoring user LR and SP during scheduling

(arm has banked registers meaning depending on mode SP, LR, and CPSR are different registers)

(in all modes but system and user, there is an additional SPSR register where the old CPSR is stored during an exception/interrupt)

i don't know if userspace is for sure 100% stable but it's a heck of a lot more stable than it was yesterday

[glass heart]

daaamn

[cedar mulch]

I just found out im mentioned in one of Boron's blog posts

of 2025

[glass heart]

you are!

[glass heart]

Im considering merging it rn

Then doing a small reorg and possibly a rebrand

If I can figure out a good name

[scenic bronze]

moron

more boron

[near panther]

boron NT

its like boron, but better

[random sleet]

ports of what

[cedar mulch]

fireworks test

[random sleet]

oo

is that in C?

[cedar mulch]

yes

its only technically a port

[random sleet]

i might have to translate it to rust

[cedar mulch]

it uses similar logic to his however it is different code

[random sleet]

or i link against it from foreign code

:P

[scenic bronze]

are you using rust again

also I just rewrote the fireworks test in zig btw

wait zinnia thread disappeared, ah no nvm its just inactive

[random sleet]

https://cdn.discordapp.com/attachments/819519506572771388/1424183808302780628/WeDoALittlePosting-ny5nqrc4jnsf1.gif

i renamed menix to zinnia and refactored the entire codebase

right now i'm writing a portable libudev replacement

[scenic bronze]

idk how I'm pretty active and I miss so much stuff

[random sleet]

i didn't say it anywhere

[glass heart]

you might want to!

it's a very useful scheduler & memory manager stress test

[random sleet]

hm

[random sleet]

link?

[glass heart]

thats your message

[random sleet]

oops didnt mean to reply

[glass heart]

https://github.com/iProgramMC/Boron/blob/master/drivers/test/source/fworktst.c here

basically every firework particle is a single pixel

[random sleet]

i wonder if I'll have any concurrency issues

because technically rust should protect me here

[glass heart]

I have officially merged the arm port after over 100 commits!

[glass heart]

now I think I should implement ext2 write support

or signals

or something

idk what i should do

[glass heart]

im writing an article for my ramblings where i describe the exact process i went through... it should come out in the next few days if i don't forget

it's a very long and mixed story

[glass heart]

switched to a kernel-global key code list. keyboard drivers will now interface through it instead of using their own scancodes.

[limpid cloud]

ARM, right?

[glass heart]

this is old news. but yes!

[glass heart]

i should rename this to CEMENT

an OS with the code style and looks similar to NT, with stability similar to ME (for now), and the flexibility/portability of CE (soon)

[bronze egret]

[crude arrow]

In Ukrainian, this would translate into "this is a cop" (derogatory). I like the name borongo.

[brazen nimbus]

nah your code is more stable than ME

what about cent- oh wait nevermind

[glass heart]

i'm working on shutdown support

this will be important to get right because we have a complex caching system and any failure to flush data to disk properly will be met with errors in e2fsck when i implement ext2 write support

[glass heart]

the first traces of a proper shutdown flow are here

for now, all the processes are terminated without regard for user data

now the screen gets cleared and a power-off message appears:

[noble sphinx]

incoming acpi support?

first os here i see that actually makes a working shutdown flow before shutdown support

[echo saffron]

astral has a shutdown flow too

and acpi shutdown too, i guess

[noble sphinx]

yeah but that was added after acpi support iirc lol

[echo saffron]

but idk how "proper" it is

i see

[noble sphinx]

but yeah probably astral and managarm

maybe keyronex also

that have some sort of a shutdown flow

[echo saffron]

proper shutdown is such a chef's kiss

something i've always overlooked

[noble sphinx]

yeah u dont think about it much in a hobby os usually

[glass heart]

no

[glass heart]

i need a working shutdown flow because of my complex data caching mechanism

if i don't implement a proper shutdown flow then i might wake up with no data actually being written back to disk

or even worse

half the data being written

[noble sphinx]

why not?

[glass heart]

i don't feel like implementing it yet

[noble sphinx]

oh ok

[mossy thicket]

mintia has proper shutdown...

[noble sphinx]

how could i forget, my apologies

[glass heart]

so how do you test anything

like your fs drivers

[noble sphinx]

fsync(2)

[glass heart]

why of course

i mean i could just implement sync like that

making the modified page writer write back pages to the disk would be fine

however

what if data is still mapped in memory

then with my current system that data wont be written back

[echo saffron]

i don't

:^)

bold of you to assume i ever got to that. lol

[glass heart]

even my previous OS has a shutdown flow

only semi-proper i'd assume but it does

it flushes all its block caches (🤮) and declares itself poweroff ready

[mossy thicket]

generally it goes something like send sigterm to all processes then wait 5 seconds or until all processes are dead then send sigkill and wait 5 seconds or until all processes are dead then flush all dirty pages then shut down

[glass heart]

    This module implements the shutdown procedure.
    
    The shutdown procedure performs several tasks:
    
    - Ensures every process on the system, except for the system process, is terminated
    
    - Unmaps every system cache view from system memory
    
    - Flushes all modified pages to their backing stores
    
    - Finally, it shuts down the system through the HAL.```

yeah something like that

[mossy thicket]

the division of responsibility between init and the kernel for this varies

[bronze egret]

now I wanna implement proper shutdown, lemme put that on my todo list

[glass heart]

i'll make the window manager, or whoever is the root process, manage all the nice guy termination logic

the system service OSShutDownSystem will eventually be restricted to when you have the shutdown capability (security isn't yet a feature)

and it will fully terminate every process

[noble sphinx]

are you going to eventually roll your own aml stuff?

[glass heart]

no

this is PURELY for the sake of flushing everything possible so that I can test my ext2 write support

when I get to it

[noble sphinx]

yeah but eventually u still want to be able to shut down right

[glass heart]

i sorta wanted to start with that first, but realized i wouldnt be able to test whether my changes were breaking things

[glass heart]

i do

i'll probably just slap uacpi on it

i don't wanna deal with the cancer that is AML

it should've been a simple register write

[noble sphinx]

fair

[glass heart]

https://github.com/iDroid-Project/openiBoot/blob/master/plat-s5l8900/pmu.c#L40 iphone did it right

but anyway yeah

ACPI support will be added at some point but i don't feel my kernel is nearly mature enough yet

[noble sphinx]

// I have no idea what this does, it's from the iOS kernel. lol

[glass heart]

of course, for undocumented hardware, you gotta follow what the software meant for that hardware does

[noble sphinx]

pmu_write_reg(0x0d, 0x1, FALSE); // Only ONKEY can wake us up. so if u write 0 here you will never be able to wake up again?

[glass heart]

i'd hope that's not how it works

that would be incredibly bad

[noble sphinx]

funny design

[glass heart]

frankly we'll never truly know what any of this really does unless apple goes through a hefty source code leak

[mossy thicket]

That happened already

[noble sphinx]

when

[mossy thicket]

iBoot sources were leaked

yrs ago

[glass heart]

there has been a leak of iboot source code a long time ago but they apparently expunged support for early samsung chips

[noble sphinx]

a full leak of everything would be cool ofc

[mossy thicket]

It came from a junior swe at Apple who leaked it to impress the staff channel of the jailbreak discord apparently

They immediately started spreading it against his wishes and it eventually breached containment and then he was no longer a junior swe at Apple

[noble sphinx]

imagine ruining your career to impress discord mods

[glass heart]

i mean obviously

why would you do that

i would never even consider leaking source code i have access to and dont own

even if i was under peer pressure

maybe if i were under exceptional threats to my life

[mossy thicket]

Unfortunately you already leaked boron source code

[noble sphinx]

you're fired from the boron foundation effective immediately

[glass heart]

i own that code so i can do whatever i want

[noble sphinx]

now the board owns it

[glass heart]

after implementing shutdown support and ext2 write support i think i can finally get started on the window manager

i kinda cant wait but oddly im not that excited

i will be when i finally see pixel move on screen

and then more pixel move on screen

[brazen nimbus]

I take it I should start talking in here for communication this project? I'm slowly reading it.

What does the flow for installing this onto an HDD look like as of now?

I know there was one for your previous OS in the github

[glass heart]

There is a tool called limine-deploy where you deploy Limine's boot sector and stage 2 onto a hard drive

Then you paste limine-bios.sys into /boot, I believe?

And paste the boron files

And then in /limine.cfg paste the config

Or something like that

read the limine install guide

[glass heart]

hmm

i seriously should consider

somehow tracking every single modified page on the system

mapped or not

and enable saving it to memory even if it's mapped

i think the current system does work but it's not very flexible since you can't do a complete fsync-type operation at any time, and even if you could, it wouldn't save everything

[mossy thicket]

This isn't easy to reliably do because you'd need to reset the dirty bit on all mappings of that page before writing it out

[glass heart]

Technically you don't have to do this, but it would cause massive inefficiency by writing potentially the same data twice or more

So yes, not easy to do efficiently and reliably

[brazen nimbus]

I see okay

[glass heart]

how much use would a version of boron without virtual memory support be 🤔

probably not very

it would still run programs but a lot of things would be a lot less efficient

and you'd run out of memory faster since it's almost impossible to implement transparent swapping

and i dont feel like adding ways to manually swap

[primal gorge]

It'd be an interesting challenge to write and make use of it, how much of the kernel assumes you have virtual memory?

[glass heart]

a couple syscalls have VirtualMemory in their name

and my ELF loader relies on virtual memory to map files

[noble sphinx]

sounds pretty easy, you just do nothing on map and assume you have one virtual space

so in the elf loader you just try to "allocate" the space where you want to map it

if it's already taken by something else then that's it

same for mmap or similar syscalls

the only thing is u have to disable demand paging

[glass heart]

the problem is that a lot of the systems that dont have virtual memory also have pitiful amounts of RAM

like 1 MB

2 MB

i could technically make it work but you'd run out of memory trying to do one thing

at least with virtual memory i could implement swapping and that could let me juggle a few things in and out of memory

[glass heart]

Apparently the init system is supposed to handle mounting stuff in unix systems?

I don't know how I didn't think of putting drive mounting in userspace, but did think of putting significantly more complicated things like OSReplaceProcess outside the kernel

[random sleet]

i just changed that a few minutes ago as well

[glass heart]

(fun fact: as a consequence of OSReplaceProcess being almost entirely implemented in userspace, after a certain step, if an error happens, the program just exits with a status code)

[glass heart]

i literally saw it in your project

[random sleet]

💀

[glass heart]

which is why i posted about it

[random sleet]

great tho

[glass heart]

this kinda sucks but it seems better than the alternative which is to create a new process and then literally swap the entire process structs between them

and exit out of that other process

although that doesn't sound like such a bad idea anymore thinking about it...

[glass heart]

yep, thats the thing i remembered

should've done this on april fool's day

[fast prism]

i love this image

[modern cradle]

years ago there was a meme image for "windaaz too thoosand", windows tyneside edition

it was really funny, but i cant find it any more

yay found it

[glass heart]

hey

C++ support with frigg is in (native boron, not mlibc)

The code in question:

finally, I can get started on my window manager*

[glass heart]

i guess before i start window managering i will need to implement

• a mouse driver (as part of the combined ps/2 driver)
• a message passing mechanism

[glass heart]

i will admit, i have used AI, but only for proofreading, and only a few years ago when AI was still new; no code was written by AI here and I didn't use it to conceive any design elements.

all of the code and design is purely brain & hand-made, and that isn't gonna change anytime soon.

Boron (not vibecoded)

[glass heart]

this is why I will not be creating a thread in #1495061753715884222 for boron

[glass heart]

also all the messages are here and it'd be kinda weird to try to move

¯_(ツ)_/¯

[wet marsh]

what exactly does boron native mean? do you mean like your own libc or your own executable format

[mossy thicket]

Boron more like bonor

[glass heart]

give me context please

i usually talk about "boron native" as in only linked using boron libraries and libboron.so

[limpid cloud]

windows cement

[glass heart]

thinking of how i should expose pipes in my OS to userspace

also thinking about the posix pipe(2) call

I think I will refactor the way terminal objects are implemented

They're basically a fancy pipe duplex

so I think I should split it into two: a pipe duplex object type and the actual terminal object type

[uncut lance]

i recommend STREAMS

[glass heart]

what are they and how are they special?

[uncut lance]

a stream is composed of a stack of modules terminating into a 'driver' module

for example a pty might be done like this

for a pipe you can cut off everything there between the stream head and the terminating modules

[glass heart]

what are ptem, ldterm and ttcompat?

and pckt

and these seem to be layers between the user I/O read/write functions and the bare pipe duplex

[uncut lance]

there's nothing to require they be twisted at the bottom, they can just as well not be

ttcompat is for translating old ioctl semantics; ptem provides ioctls like TIOCGWINSZ/TIOCSWINSZ; ldterm is a line discipline module

[glass heart]

i see

[uncut lance]

it's the stacking (and the asynchronicity) that's the distinctive principle

[glass heart]

what other examples of STREAMS usage do you have?

[uncut lance]

regular TTYs (also push ldterm), FIFOs (a single stream whose bottom is twisted around to itself), networking (in keyronex, usually a socket module pushed over a transport provider like TCP or UDP)

[glass heart]

oh while we're on the topic of networking

are you considering implementing TCP/UDP in userspace and just implementing IP support in the kernel and stuff?

or even lower down to the bare packets?

[glass heart]

i took a break from my break from desktop environment work and decided to try and get GPIO (and the buttons) working on the iPod touch

I got the two buttons to send interrupts and my OS to receive them, however I think I might wanna move it to the HAL actually

[glass heart]

I've moved the GPIO controller driver to the HAL and created a new driver, ipodbtns

And I'm now testing a recursive KeDispatchInterruptNumber, which seems to work

first, the GPIO's interrupt handler is issued, and then it decides "oh, this is actually for 64+GPIO IRQ#" and fires it there

There is a double call to HalEndOfInterrupt but it doesn't do anything with an InterruptNumber more than 63 (0-63 are the regular IRQs, 64+ are the GPIO IRQs)

[glass heart]

managed to get my hands on a working iPhone2G (spent quite a bit on it though)

now, all 3 s5l8900 devices (iPhone 2G, iPhone 3G and iPod touch 1) run boron

as of now, they all work the same

however a lot of things are still different

like multitouch

[noble sphinx]

Whats the end goal for that port?

[glass heart]

the MAIN goal is just so I can claim boron works on armv6

(and it does)

(actually pretty well)

several other goals:

• play Bad Apple!! on the iPod touch 1 using the in-built piezo speaker (you can't arbitrarily program the piezo from iOS)
• possibly implement some kind of multitouch mobile GUI system that would run on those as well as some more pocketable devices
• and push my own boundaries, this is almost all unexplored for me

[noble sphinx]

I see

[glass heart]

also the iphone 3G is pretty cheap, and also hacked to hell and back

so its a reasonable alternative to buying a 32-bit arm PC board like a raspberry pi model B, which are kind of a rarity where I live

also it's cool to finally have broken out of x86 land with a real hardware platform (as opposed to just working inside qemu-virt)

one more thing, i guess i just find these devices cool because i've never had an idevice as a kid and it's really cool to see what was going on while i was growing up

[noble sphinx]

that thing doesnt really have a device tree right?

[glass heart]

actually it does, but it's not a kind of device tree that linux would understand

https://gist.github.com/dizimka/2922441 for the iPod touch 1G

I'm not using it though.

for several reasons:

• boron has no concept of a device tree
• I don't know where I can find the device tree in RAM/how I can read it
• the device tree is in IOKit format anyway

[noble sphinx]

oh ok

[undone sky]

you can probably find xnu from the era and figure out how they get it

[glass heart]

maybe, but i honestly dont really care

[uncut lance]

i remember having an ipod touch gen 1

good times

[glass heart]

theres like 1 configuration of each model

with different nand sizes, sure, but the same controllers

[glass heart]

oh cool

i should definitely do the bad apple thing

[noble sphinx]

I loved my 3GS

[glass heart]

the gen1 ipod touch never had a speaker

only thing it had was a clicker

kinda like an ipod nano

which could make little bleeps and bloops

[uncut lance]

i wonder if i had a 2nd gen then, i thought mine had a speaker

but that's a long time ago so i might be misremembering

[glass heart]

from what i can see it's similar (in terms of how it's driven) to a PC speaker, since both are driven by periodic timers

according to openiboot's source code

[glass heart]

do you remember it being particularly curvy on the back?

that wasn't how the 1st gen looked

the 2nd and 3rd gens' backs were bow-shaped

[uncut lance]

hard to say, it was 17 years ago

i thought i would remember if i looked at pictures but i don't

[mossy thicket]

iokit's device tree is built dynamically by the drivers probing the hardware

at boot time

It's not like a thing they pass into the kernel

[glass heart]

probably true on Mac OS, but I'm not sure about that on iOS

the kernelcache most likely doesn't dynamically poll the hardware since it's built for each specific model of iOS device

according to https://devos50.github.io/blog/2022/ipod-touch-qemu/:

Subsequently, the kernel reads the device tree included in the NOR image.

(the NOR image includes the iBoot bootloader as well as other information about the device)

[undone sky]

kinda. there are two device trees afaik

there is the iokit one (which is just an internal repr?)

and the real one you get from firmware

[glass heart]

on x86 does firmware give you a devicetree?

does that mean that for hackintoshing they have to inject their own dt?

[undone sky]

no on x86 there is a different way of setting it up

[glass heart]

ah

wait, ACPI has device tree-ish info doesnt it?

[undone sky]

but on arm they have their own nih device tree

[undone sky]

yeah

[noble sphinx]

i wouldnt even say ish, its a more complex device tree with methods and objects

[undone sky]

and with four letter names because memory is that expensive

[glass heart]

the NOR flash inside idevices also uses 4 char codes for data inside of it

[undone sky]

yeah but thats different

[real ferry]

How do you plan to make the DE look like?

[uncut lance]

the of device tree is also supposed to be like that but the linuxers tragically stripped the methods

we could've been drawing our logo to the screen if only they hadn't

[noble sphinx]

who needs methods if u can have everything as a kernel driver instead

linux is the only kernel as we know

[glass heart]

I actually haven't decided what it would look like

One of my visions though is to have an old-style (pixelated) interface and a new-style smoother interface

[undone sky]

tbh if you only have one kernel it isnt actually that crazy

[crude arrow]

But (fortunately) there is no "only" kernel in the world, moreover not just linux as the one and only, so what they did is pure lamery and why they did so is their arrogance/haughtiness. This is not how standards are being created.

[crude arrow]

I wouldn't expect from the "linuxers" anything else. I blame arm. They just could have adopted ACPI from the beginning and send the lunuxers to take a hike with their castrated, "linux only" fdt.

[undone sky]

ngl im not sure acpi is much better, you are basically pretending to be windows

and yeah linux is not known for thinking about others lol

[glass heart]

well, apparently i had a regression sneak up on me

several, actually

• OSDLL wasn't initializing all the needed fields in an __attribute__((constructor)) function which mlibc doesn't play nice with
• mlibc had outdated sysdeps (system call definitions)
• the commonmakefile for user programs was apparently including crt0.o with libraries too which meant libboron.so couldn't be used as a dependency by normal applications (or, well, any application, since the dynamically shared part of mlibc depends on libboron.so)

also I discovered that for ARM32 I don't appear to need freestanding headers as the arm-none-eabi-gcc toolchain has these headers already. although they're actually not a subset of gcc's and libstdc++'s normal header set, but rather the entire thing, I can just include the ones that work in a freestanding environment, and that I (and frigg) need, like <initializer_list>, <new> [I implement operator new and operator delete in libC++Support], etc.

right. next up is probably a way to pass messages between processes

sorely missing right now

it'll probably be similar in scope to sockets (with a difference between "datagram" and "stream" methods)

[glass heart]

okay, I've drafted up a plan for sockets (a/k/a incomprehensible gobbledygook which I'll need to refine further)

I make references to "TCP" and "UDP services", this is intentional as I plan on implementing a network stack in userspace, when I get started on that.

I plan on implementing just enough on sockets to get started on the window manager. (and the object manager shenanigans)

... and I still need to figure out a way to share object handles across process boundaries

a dumb way would be to allow a user process to temporarily link their objects in the object namespace under a hidden path like /Hidden/{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}, and it'd be grabbed by the second process and quickly unlinked

this would be a solution to the problem of allowing the window manager to share memory with clients so that they can draw their windows on the screen

at the same time this is kind of dumb because it conflicts with another plan of mine which was to create a stacking window manager which explicitly does not use framebuffers for drawing to the screen... but then what else could I use? a temporarily allocated buffer? not sure.

I could implement two tiers of window manager, one stacking, and one half-stacking half-compositing, where the latter actually just gives windows a surface buffer to draw to

[glass heart]

TL;DR I want to modify some stuff in the object manager to support weak references, objects weakly linked to the object namespace (ephemeral, get deleted when unreferenced like anon objects are), implement sockets (stream + datagram mode), andn a bare-bones API for them, and expand OSWaitForMultipleObjects to support poll()-like functionality

I would like some feedback on this plan. (please)

[glass heart]

thinking about it again, and meh. i don't think i'll do a unified stream mode + datagram mode socket

I'm thinking of a couple things instead:

- for discrete message passing (datagram mode), add a port object which can have the following:
    - an arbitrary message of up to 65536 bytes
    - up to 4 objects can have their ownership cloned through a message
    - some additional metadata (like perhaps an address)
- for stream mode communication, could reuse code from the terminal object or create a separate pipe duplex object.
    - operations other than reading/writing would be performed through an IPC call to the TCP service
    - although this might not be a great idea... maybe blocking until the data is sent via the wire is important
    - I'll have to design this more in-depth

[glass heart]

alternatively I could look into how NT does LPC/ALPC and replicate that

sounds better?

[glass heart]

looked into NT LPC for a moment, it looks remarkably similar to sockets

it's kind of like a mix between TCP and UDP sockets

where in normal sockets you'd do something like

struct sockaddr* psa = ...;
size_t sa_len = ...;

int fd = socket(AF_INET, SOCK_DGRAM, 0);
bind(fd, psa, sa_len); //bind it so that whoever's trying to connect to it can find it

on NT you call NtCreatePort with a name (and optionally, a security descriptor)

and it puts that name in the object namespace

[glass heart]

I say this because while the connection flow appears to be similar to the one from TCP, messages are sent in distinct "datagrams" instead of a stream

http://www.zezula.net/en/prog/lpc.html looking at this rn

NtListenPort (server) -> NtConnectPort (client) -> NtAcceptConnectPort (server) -> NtCompleteConnectPort (server) -> NtReplyWaitReceivePort (server)

[modern cradle]

NtReceiveReplyAcceptConnectCompletePort?

/j

[glass heart]

hmm

[uncut lance]

one of the things i like about STREAMS is that stream and datagram (also canonical TTY) all get a common handling

[glass heart]

how does that work?

[uncut lance]

a stream head is the interface to a stream and receives discrete message blocks; a read-mode flag determines whether it, for ever read, a) disregards the discreteness of message blocks and just returns as many bytes as requested or available from all the message blocks; b) reads only up to the end of the first queued message, discards it afterwards even if some of it wasn't read (SOCK_DGRAM type behaviour), or c) reads only up to the end of the first queued message, keeps it if partially-read, but offsets the beginning (canonical TTY behaviour)

[glass heart]

truthfully I haven't looked into STREAMS that much... so I don't know the basic idea behind them

[glass heart]

c) reads only up to the end of the first queued message, keeps it if partially-read, but offsets the beginning (canonical TTY behaviour)
as in, only reading up until the next line, or what?

[uncut lance]

yeah, modelled as each line being one discrete message block

[glass heart]

i didn't know canonical TTYs actually had such a behavior

I implemented something stupid to implement line-by-line input

IO_RW_FINISH_ON_NEWLINE

Which, as the name would suggest, finishes reading on newline

Fully supported by (only) the terminal object, and conforms to the terminal settings which you can configure through an IoControl

Scratch that

Turns out I don't!

(And also that it's supported by all pipe objects, actually)

[glass heart]

finally

the ipod touch 2g can run boron now