<heat>
i guess it depends on the system. linux would not call that a driver, would just call it a filesystem
Turn_Left has quit [Read error: Connection reset by peer]
zzo38 has joined #osdev
<gog>
i would call it a layer
<gog>
or a filter
<gog>
or an application assistant service responder
<gog>
a file factory
<gog>
heat when i make c# linux its entry point is going to be DI container
<heat>
dependency injection all the things
<heat>
ever
<heat>
if you inject dependencies are you natty
<gog>
no
<gog>
it gives you an unearned advantage
<gog>
also at the gym i go to there's a bar that has the phrase "stay natty" welded onto it
<gog>
sadly i take steroids
<heat>
reverse trt
<Ermine>
DI = ?
<gog>
yes
<heat>
dependency injection
<gog>
dependency injection
<zzo38>
My idea about keyboard manager in a system: The virtual key codes are 32-bits. Codes 0x200000 to 0x212120 are not used; codes 0x212121 and greater are long character codes. Codes less than 0x200000 are all other codes; some of the bits are used for modifiers (e.g. Command, Meta, Numpad) and others specify which virtual key or special code (e.g. bracketed paste, IME, etc).
netbsduser has quit [Ping timeout: 255 seconds]
<zzo38>
Codes 0x000 to 0x0FF are characters in the currently selected short character set (commonly none will be selected, but sometimes it is useful to select one; e.g. APL character set when doing APL programming, PC character set for DOS emulation, etc). Codes 0x100 to 0x17F are always ASCII codes (including the control codes; but the printable characters would commonly be used in combinatino with Command and/or Meta).
jimbzy has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<kof673>
you say DI i say interceptor pattern Interception - Dependency Injection DI Interception Exploring the Concept of Interception in Dependency Injection
<zzo38>
The other codes will be used for directional keys (one bit per direction; this allos no bits for centred (e.g. numpad 5 with numlock disactivated), and two bits at once for diagonals), function keys (F1, F2, etc), and other possible functions. Some are "specials", e.g. Void, Begin Paste, End Paste, etc.
<zzo38>
I had also consider for the clipboard to be managed by the keyboard manager too
dgz has quit [Remote host closed the connection]
<zzo38>
For implementing an operating system inside of another one (e.g. in case you want to use the existing drivers, or to run programs for the other system at the same time), will also be consideration of the security of the system, if native code is used.
<childlikempress>
zzo38: bad, you are mixing abstractions. input translation should be more properly separated
<childlikempress>
and please for the love of god don't reinvent code pages. we have unicode now, just use it
<childlikempress>
i mean do whatever you want but don't reinvent code pages
<heat>
utf-16 utf-16 utf-16 utf-16
<childlikempress>
utf16 is fine it's just PESSIMAL
<heat>
use the inverse endianness utf-16 of whatever is the host cpu
<childlikempress>
:D
<zzo38>
How should you deal with input translation and other stuff dealing with keyboard management, then?
<childlikempress>
you have to have multiple layers. don't try to stuff everything into a single 'key code'
<heat>
kernel just tracks which keys are pressed
<heat>
then whatever's reading that takes care of translating to meaningful keypresses (i.e shift+a = A)
<childlikempress>
oh also 'bracketed paste' should not be a thing. unix-vtxxx terminals require it because something something in-band something something godawful sync, but you're not being compatible with that anyway presumably (right ... right ... right?)
<zzo38>
(Also, in order that network transparency and emulation will work, the same endianness is used for I/O regardless of computer type, although programs will internally use the native endianness for their own calculations and internal data, of course)
<heat>
childlikempress: also no utf-16 is not fine do NOT tolerate utf-16
<heat>
it's the worst of both worlds
<nikolar>
yes
<childlikempress>
heat: like
<childlikempress>
yes obviously out of all the choices utf16 is not the one you should pick
<zzo38>
My idea is considering, the keyboard manager (which is a part of the GUI system and not the kernel; and this is the application interface specifically, anyways), the IME (which might be a separate program but is seen as the keyboard manager interface by applications) and keyboard manager, will handle character translation of course.
<childlikempress>
but compared with codepages i'd take utf16 any day
<heat>
i'd need to think about that honestly
<nikolar>
just use utf-8 and don't think about it
<zzo38>
So, it does handle "shift+a" as "A" and stuff like that, depending on the keyboard mode (e.g. text-entry mode, command mode, game mode, hybrid mode).
<childlikempress>
zzo38: the main thing is that an "A" text input is not the same kind of thing as a shift keypress or an a keypress, and you should not try to force one data structure to be both at the same time
<zzo38>
Well, the application will only care about it one way or other at once anyways. The application will not care how that is achieved; simply that it wants text input and receives either text input or a command keycode. Similarly if you want "Command+?" then you will not have to worry what key combination you need on your keyboard layout for a question mark, even though it is a command code.
<zzo38>
It is true it is not the same kind of thing as a keypress, but that is because it is not in "keypress" mode.
<zzo38>
Obviously, if you want to track individual keys pushed and released, that is not using the "virtual key codes" that I had described (which do not handle released keys, anyways).
<zzo38>
Also, the use of code pages in the keyboard manager is specifically not always used anyways; it is only in case when it is helpful for the application to request such a thing.
<zzo38>
(And, a code page can easily be added if necessary; although, if you do not have suitable fonts or a suitable keyboard layout, then a fallback is necessary, but still it will work. It can also be disabled.)
<zzo38>
About bracketed paste, it is not only for pasting from the clipboard, but can also be used with IME.
<Ermine>
utf-16 is a thing I definitely hate in windows and efi
<zzo38>
Which character encoding is best would deepnd on the situation, though.
<childlikempress>
out of all the things to hate about windows i think utf16 is pretty far down the list
<childlikempress>
although doesn't windows have a thing where it's rly inconsistent about encodings or something?
<zzo38>
I dislike UEFI anyways, but use of UTF-16 is only one of them
<zid>
yea it does a weird thing where it encodes every letter of the alphabet differently
<Ermine>
childlikempress: yes it has. The one lul moment in Windows in Russian is that nslookup outputs stuff in two encodings, so you see garbage no matter what code page you've taken (1251 corrupts one part, 65001 corrupts another)
gog has quit [Ping timeout: 256 seconds]
<zzo38>
(I think that UEFI is overly complicated for what it should have to do, and has badly designed parts, etc)
<zzo38>
Although, maybe it is right to have one message for keys and one message for text; the message for keys is not used if it is text-entry. However, maybe there are both advantages and disadvantages to such a set-up.
goliath has quit [Quit: SIGSEGV]
<zzo38>
I think that a separate Command and Control key (like Macintosh has) is better, though.
navi has quit [Ping timeout: 252 seconds]
stolen has quit [Quit: Connection closed for inactivity]
qxz2 has joined #osdev
rustyy has quit [Ping timeout: 264 seconds]
aejsmith has quit [Ping timeout: 256 seconds]
heat has quit [Quit: Client closed]
aejsmith has joined #osdev
gbowne1 has quit [Read error: Connection reset by peer]
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
GeDaMo has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
m3a has quit [Ping timeout: 256 seconds]
rustyy has joined #osdev
Tetsuo has quit [Quit: WeeChat 4.3.2]
aejsmith has quit [Ping timeout: 255 seconds]
aejsmith has joined #osdev
CryptoDavid has joined #osdev
Left_Turn has joined #osdev
gsekulski has joined #osdev
Turn_Left has joined #osdev
<gsekulski>
Hey, where can I find "networking stack" documentation?
Left_Turn has quit [Ping timeout: 256 seconds]
<Ermine>
networking stack of what
<gsekulski>
netfilter
<Ermine>
Somewhere at docs.kernel.org
<nikolapdp>
q
<GeDaMo>
u
<nikolapdp>
a
<gsekulski>
b
<nikolapdp>
l
aejsmith has quit [Ping timeout: 255 seconds]
aejsmith has joined #osdev
<Ermine>
quaso!
netbsduser has joined #osdev
<chiselfuse>
hello, anyone who uses ida can tell me what the numbers 000, 008, 050, 058 (orange in the left column) mean? i thought they might be the offset from the start of the function but that doesn't correspond to the addresses say in the leftmost column
<GeDaMo>
It changes when the stack is updated "push rbp" and "sub rsp, 48h"
<Mutabah>
it goes up by 8 on each push
<chiselfuse>
just looking at it now it looks like it the stack growth
<chiselfuse>
yea
<chiselfuse>
i wonder whether you can confuse it, it needs to simulate the execution to calculate it, doesn't it?
<chiselfuse>
what if i take return from a syscall and decrement rsp with it
<chiselfuse>
it can't know
<GeDaMo>
Can't know what?
<chiselfuse>
if i do a read syscall (i don't remember but assume the return is stored in eax) and decrement rsp by eax
<chiselfuse>
how can it know what the stack growth will be
<chiselfuse>
GeDaMo: in this code it decrements rsp by 0x48 and it becomes 0x50 in size (it was previously 0x8)
<chiselfuse>
does that make sense?
<GeDaMo>
You'd have to try and see what it did
CryptoDavid has quit [Quit: Connection closed for inactivity]
goliath has joined #osdev
gog has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
<gog>
meowdy
* mjg
burps
<gog>
mjg what is your favoerite editor
<gog>
which editor is the most OPTIMAL
* mjg
looks around
<mjg>
do we need to keep up appearances here
<gog>
humour me
<mjg>
between you and me, and the fucking dog barking outside
<mjg>
i don't know what would be a good editor today
<mjg>
at the moment i'm fighting with neovim, which in itself looks extensible enough to qualify
<gog>
what editor does the dog like
<mjg>
it's too busy barking out dog principia to respond
<mjg>
i *suspect* for something like rust, go or whatever else higher popular dev all the popular options are good enough, and a particular choice is mostly a matter of taste
<mjg>
s/popular dev//
<mjg>
and i'm even including vscode here
<gog>
i bet i know its favorite email client
<mjg>
mutt, ez
<gog>
it's mutt
<gog>
sksksk
<mjg>
i only recently learne that 'mutt' is even a word :-P
<gog>
i tried using vscode with my not .net project and it just kinda got in my way
<mjg>
while reading a thread with people complaining about dogs
<mjg>
that is *probably* the taste thing
<mjg>
it's not rolling the way you want
<gog>
also i can't figure out how to make the LSP work
<mjg>
i thought with vscode things just work
<gog>
works automagically with c#
<mjg>
fwiw they do with common lsp bundles
<mjg>
erm, neovim bundles
<gog>
yeah i have neovim like 85% configured the way i had it before my reinstall
<gog>
i'm only now getting back into things
<mjg>
now that i have neovim i am seriously considering a git repo with my config
<mjg>
even on github
<gog>
lol
<mjg>
what
<gog>
idk that feels overmuch to me
<mjg>
putting it on github or having it to begin with
<mjg>
i have backups ofc, but my configs is the one thing i am not tracking in a repo
<mjg>
which is pretty odd
<mjg>
i even have a git repo tracking my reading list :-d
<gog>
heh nice
<mjg>
i did not add shit there this year, now i am scared to git log on it
<mjg>
8d
<mjg>
gog: what's your color theme dawg
<gog>
uhhhh
<gog>
sorbet
<mjg>
that and related themes are for neovim normies
<GeDaMo>
GUI+CLI covers all the major desktop systems
<GeDaMo>
Text only is less common nowadays
<Ermine>
Linux without Xorg or a Wayland compositor is text-only
<nikolar>
so is every bsd
<GeDaMo>
How many people run those as their desktop systems though? :P
<Ermine>
not many, but there are lots of embedded devices and servers
<Shaddox404>
Some with old hardware probably? I think a few run Alpine Linux too, since its very lean
<Shaddox404>
old = something around 2000s to 2005?
<Ermine>
alpine linux has gui
<Shaddox404>
True
<Ermine>
and it's quite capable of running on old hw
xenos1984 has joined #osdev
<GeDaMo>
Shaddox404: what are you looking for? Something to run yourself? Ideas for your own OS?
<Shaddox404>
I'm trying to understand how many of them are considering a text based OS as a full OS vs an OS with GUI as complete
aejsmith has joined #osdev
<dostoyevsky2>
GeDaMo: I wonder how hard it'd be to just write your own X server
<dostoyevsky2>
GeDaMo: I guess one would just listen to a socket and drawing stuff on the screen according to the RPC calls.. but not sure how one would communicate events back to the client
<GeDaMo>
I'm pretty sure the X protocol is bidirectional
<nikolar>
yea
<dinkelhacker>
Shaddox404: Since 99% of all servers don't have a GUI I'd say a text based OS counts as a "full" OS.
<Shaddox404>
I see
rustyy has quit [Ping timeout: 255 seconds]
Turn_Left has joined #osdev
k_hachig has quit [Ping timeout: 256 seconds]
Shaddox404 has quit [Quit: Connection Terminated!]
netbsduser has quit [Ping timeout: 264 seconds]
netbsduser has joined #osdev
k0valski18891621 has joined #osdev
k_hachig has joined #osdev
Turn_Left has quit [Quit: Leaving]
Left_Turn has joined #osdev
Turn_Left has joined #osdev
node1 has quit [Ping timeout: 250 seconds]
node1 has joined #osdev
k_hachig has quit [Ping timeout: 268 seconds]
Left_Turn has quit [Ping timeout: 240 seconds]
Arthuria has joined #osdev
dgz has joined #osdev
aejsmith has quit [Ping timeout: 268 seconds]
dgz has quit [Remote host closed the connection]
node1 is now known as timytimy
janemba has quit [Ping timeout: 246 seconds]
* geist
yawns
<geist>
good afternoon folks
<nikolapdp>
hello there
<Ermine>
hi geist how are ya doing
aejsmith has joined #osdev
<zid>
filter feeding on brine shrimp still probably
theyneversleep has quit [Remote host closed the connection]
<bslsk05>
dhansel/PaperTapeReader - A DIY reader for vintage 8-bit paper tapes (10 forks/89 stargazers/GPL-3.0)
gog has quit [Ping timeout: 264 seconds]
<netbsduser>
i had a dream last night where i was instructed on a nice way to make finer the locking around memory management
<netbsduser>
what i dreamt was this: since i am now using radix trees for all page tracking, and i need a state lock on the contents of these, i can put a 1-bit spinlock into spare space in a flags field in the page struct
<netbsduser>
that's dealt with by CAS. that gives me a per-page lock, and if your radix tree levels are page-sized, you can just use that lock to protect their entries
heat has quit [Ping timeout: 250 seconds]
<geist>
Ermine: pretty good
<geist>
lots of rain yesterday but good today. need to do some more yard work in a minute once my allergy meds kick in
<mjg>
i love rain, provided i'm inside
<geist>
netbsduser: my only thought would be whether or not that plays nice with the hardware updating the page tables with A and D bits
<geist>
probably? but it'd be architecturally specific if nothing else
<Maja>
there's no way the hardware asserts LOCK# just to flip the bits in the page table
<Maja>
hm, actually, I think I once read something about this in the SDM
<Maja>
hm, logically, it *must* do it atomically, otherwise it'll mess you up if your write to an entry has unfortunate timing relative to the hardware updating the A/D bits
<Maja>
dear dog.
<Maja>
> The accesses used by the processor to set these flags may or may not be exposed to the processor’s self-modifying code detection logic. If the processor is executing code from the same memory area that is being used for the paging structures, the setting of these flags may or may not result in an immediate change to the executing code stream.
<Maja>
does this note exist because someone complained, or did some kind of formal verification catch this?
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<geist>
and yeah it's my understanding on x86 it does use essentially the atomic mechanism to update the table bits
<geist>
but it's pretty udnerspecified in both intel and amd
<Maja>
there is a note that says that the following interleaving is possible: (1) core 1 performs an access that needs to set the A or D flag (2) core 2 writes to the PTE of the page accessed (3) core 1 sets the A/D flag on the new PTE
<Maja>
geist: yeah, there isn't really a way to do it without doing an atomic
<geist>
see there's an important detail there: if you went to say clear a page table entry, (writing 0, or just clearing the V bit) is it possible for the cpu to race with you and set the A/D bit *afteR* you clear the entry
<geist>
and the answer is not really, because both intel and amd do some sort of CAS style check with it
<geist>
but AFAICT only AMD actually documents this in their documents
<geist>
though it's just a little paragraph that says basically the cpu will validate the entry is still valid before updaing it
<geist>
which leaves some question: is it just that the V bit is set? or that it is set and all the cached bits still match?
<Maja>
it is possible for some intel CPUs to set the D bit on a page that's not R/W
<Maja>
apparently they got rid of that behavior when implementing CET
<geist>
probably not? unclear
<geist>
ARM documents all of this is excrutiating detail, but it arrives at basically the same thing
<geist>
you have to treat the MMU as effectively another cpu that is doing a CAS with you
<Maja>
(section 4.8 of SDM vol 3)
<geist>
this is why pretty much all major open source oses do at the minumum an atomic swap when zeroing out an entry, so you can harvest the last A/D bit that may have been set
<geist>
but... the question is does all of this *also* apply to the software controlled bits in the page tables?
<geist>
hardware wont mess with it of course, but as it's setting A/D bits does it also honor the SW bits?
<Maja>
wdym honor?
<geist>
like when it sets the A/D bit is it just just an atomic on that one bit
<geist>
or is it a full CAS of the entire entry, with the bits orred in
<geist>
presumably the latter, but it's not really documented in the intel/amd docs
<geist>
like, say, it could decide to only atomic on the bottom 8 bits of a 32bit entry, or whatnot
<geist>
(i forget where teh bits are locted off the top of my head)
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
chiselfuse has quit [Remote host closed the connection]
<netbsduser>
oh, i think i miscommunicated
chiselfuse has joined #osdev
<netbsduser>
doing this with actual valid PTEs is a little bit too radical for me, so a flags word in the page struct can be used instead
<netbsduser>
it isn't fine grained quite to the level of individual PTE but that's hopefully unnecessary or even counterproductive as your page faults should ideally be clustered in most cases, so you benefit from locking neighbouring addresses as well, and hopefully your multithreaded app is tending to fault quite further away
Matt|home has joined #osdev
<geist>
oooh ooh yeah i thought you were talking about using it to lock as you traverse up and down the page tables
<geist>
to allow for multiple threads to fiddle with the same structure
timytimy has quit [Quit: Client closed]
heat has joined #osdev
<heat>
netbsduser is god giving you instructions in your sleep
<heat>
if so, why is he giving you fucking LOCKING instructions instead of something else
<heat>
in any case i would advise you not to make your radix tree levels page-sized
<heat>
the page struct flags having a lock bit is pretty standard (see linux struct page), but it's not really used for the radix tree
<heat>
particularly given that you don't *really* need granularity for it, since you can rcu the whole thing
zetef has joined #osdev
gog has joined #osdev
<heat>
i didn't explain why i'm super against making the radix tree levels page-sized: for one, PAGE_SIZE - sizeof(metadata) is not a power of 2(ruins your shit unless you want a horrible non-pow2 radix tree level size)
<netbsduser>
heat: well getting instructions from god in your dreams is a fraught endeavour
<heat>
lastly, files are not really sparse most of the time, unlike the address space
<netbsduser>
heat: would be problematic, but i pack all metadata i need either into the page struct for that level or into the bits left over in entrry slots (since i only need 52 bits for the PFN)
<netbsduser>
rcu traversal of the tree is also interesting and i can add that as an additional step to my masterplan i've drawn up on how i want to scale VM logic
k_hachig has joined #osdev
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
aejsmith has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
Arthuria has quit [Ping timeout: 255 seconds]
Arthuria has joined #osdev
Ameisen_ has quit [Quit: Quitting]
Ameisen has joined #osdev
<kof673>
i don't know if they read the logs but. > I was curious about how many here are developing an OS focusing on purely text-only/CLI based UI and a CLI + GUI solution?
<kof673>
skeleton -> blood and guts layer -> skin layer
<kof673>
that's just the skin that goes on top lol
<kof673>
or, depending on "philosophy" and supposedly "sculpting" had this idea.....the latter layer(s) wrap around the former. all focus is on the former -- conway's law, the other layers will be forced to wrap/adapt/shape/mold themselves to the "core"
<kof673>
so...for that style..."focus" is being misused
aejsmith has joined #osdev
Opus has quit [Quit: .-.]
<geist>
hmm, wonder if you made the radix tree be actually 4096 entries per page by limiting it to 8 bits
<geist>
but then havint ghose 8 bits hash to something like { radix tree node address, index, data in 8 bit field } and then look it up in a giant hash table
<geist>
guess that doesn't really help because you wouldn't be able to confirm if the entry is correct in the table lookup
<heat>
smh geist suggesting pessimal solutions that DONT SCALE
<geist>
just brainstorming, please do not dunk on that, we should do that sort of stuff more
<kof673>
that is that way of thinking anyways lol https://www.mit.edu/~xela/tao.html > If the operating system is great, then the compiler is great. If the compiler is great, then the application is great. The user is pleased, and there is harmony in the world.
<heat>
the big problem there is that the radix tree level usually has a bit more metadata
<heat>
which you then run out of bits to store
<geist>
yah
<heat>
and i do want to emphasize that a single page for a single internal/leaf node is really *way too much*
<heat>
most files (in this use case) are not big, sparse thingies
<heat>
for a <= 4K file you'll have all entries unused except a single one
<heat>
and those small files are really not uncommon
<heat>
oh and dont forget that here you have the distinct advantage of being able to have the radix tree grow in depth, dynamically
<heat>
you don't need to store all levels
<netbsduser>
i think that's a fair cop
<netbsduser>
it's not very nice to need multiple pages to deal with a file with a hundred bytes in it
<geist>
sortie: i somehow got klined from your irc server
<geist>
i wrote a perfectly valid :D to the D: channel!
<netbsduser>
as i do all read() and write() through the page cache by default it could be a real problem
<netbsduser>
as there's no avoiding the creation of the cache
<zzo38>
My idea is to have command-line and GUI together. However, many operating system they don't interact well together; but I have idea how to make it interact better between command-line and GUI.
theyneversleep has joined #osdev
cow321 has quit [Ping timeout: 252 seconds]
<netbsduser>
for the case of small files i suppose one thing i could legitimately and peacefully do would be to not do it through the page cache initially - allocate some smaller buffer, as soon as we need to outgrow it, then copy that into the newly created page cache
<netbsduser>
that's what i'm thinking of for cases like e.g. a makefile which is including thousands of dep files generated for each source
<netbsduser>
but that's very much a bit of a hack
<heat>
ugh dont bother
<heat>
seriously, sounds like a boatload of trouble
<netbsduser>
it's for read/write i/o only of course not mapped, that really would be trouble
vdamewood has joined #osdev
<netbsduser>
but my feeling is that if a file which wasn't open before, which is short, is opened only for reading, then someone wants to read it, then this is not unreasonable
<heat>
there's a nice optimization in linux's xarray (radix tree) that i haven't done before
<heat>
basically if you have a single entry at #0 you can use the top node pointer for that
<heat>
and that shaves off a bunch of space overhead
chibill has quit [Ping timeout: 255 seconds]
chibill has joined #osdev
dude12312414 has joined #osdev
<netbsduser>
heat: a nice trick which is a more general version of this trick
dude12312414 has quit [Client Quit]
<heat>
doing a separate "here's a small buffer thats smaller than a page" is something i would really never consider due to all the horrible special casing you'll need, for dubious gains
* Ermine
gives gog a piece of cheese
<heat>
particularly in a traditional VFS where struct page/folio and filesystem IO are married
<netbsduser>
in the really traditional vfs it was bufs that one dealt with
* gog
fascinate
<heat>
that was traditional 40 years ago :)
<netbsduser>
now it's uios
<netbsduser>
i don't have uios (i have a different sort of scatter-gather list) so i can do it painlessly
<heat>
does the bsd vfs not have a readpage?
<netbsduser>
like sun vfs they have getpage(s) and putpage(s) but those can be implemented in terms of the read/write vops
<heat>
how?
<heat>
they're objectively very different ops
<netbsduser>
well, read in to the page, write out from a page
<heat>
and do the read/write not use getpage?
<netbsduser>
do you know what, they might do
<netbsduser>
i am probably projecting my own design here
<heat>
i have genuinely no idea because i'm linuxpilled
<netbsduser>
i have read/write ops (which are currently used solely by the pager) that read/write a scatter gather list
Matt|home has quit [Quit: Leaving]
<netbsduser>
i will check quickly
* vdamewood
gives gog a fishy
gbowne1 has joined #osdev
<netbsduser>
yes, the read/write vnode ops are what the read/write syscalls invoke
<netbsduser>
and those will in the trivial case on netbsd map a UBC window and user memcpy to/from it
<heat>
>UBC window
gbowne1 has quit [Remote host closed the connection]
<heat>
i must not speak
<heat>
if i speak i am i big trouble, big trouble
gbowne1 has joined #osdev
<netbsduser>
on netbsd the default implementation of getpages uses bmap + strategy vops to do the actual I/O
<netbsduser>
UBC windows will use the direct map on 64-bit machines
<netbsduser>
rather than mapping awindow proper
aejsmith has quit [Ping timeout: 255 seconds]
<netbsduser>
but only if certain conditions are met, mainly that the file is not currently mmap'd anywhere
* gog
chomp fissshy
<gog>
nooo it'ss doing it again
<gog>
i can't live like thiss i'm going to get a new computer
<gog>
ok it seeems to have stopped sponateneously
<gog>
yes i deliberately chose many words with the letter s