| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> show me the data; locality is *exactly* like linked lists (and linked trees)
<0> all of which is handled by arena allocation
<0> i.e. a slabs of nodes
<1> http://resnet.uoregon.edu/~gurney_j/jmpc/skiplist.html
<0> that's a non-argument. I was hoping for something intelligent, like beeing dubious about using PRNG
<0> that's just a really bad implementation
<0> the real winner is unrolled skiplists where you basically unroll at multiples of cache line sizes
<1> ah, well that's reasonable
<1> how are you using skip lists for the path stuff?
<0> i'm not
<0> i'm pondering
<1> rather, how are you thinking of doing it?
<1> (my brain stops working *good* at close to quitting time)
<1> (lately)
<0> i'm actually thinking of not doing, but rather have a lazy node loader based on a patricia trie
<1> ah
<0> s/not doing/not doing skiplists
<1> ah
<0> would be a fun experiment
<1> what i was trying to get at before with my imp is that different FSs seem to benefit from varying implementations at that level
<1> so i abstracted the node concept into an interface
<0> the VFS won't reveil the ADT choice, no
<0> anyway, all devices are real objects and they are rooted in the same object. What I want is to be able to quickly locate and (sub)path from that root.
<0> whether it leads to a file system, a system node or whatnot
<1> ah, right
<1> in my imp. the generalized VFS manager handles caching nodes based on reference status, hash value, and a last chance algo
<0> right
<0> hash over what?
<1> it's partially filesystem dependent. an FS driver participates in the value generation. the purpose is to allow multiple VNodes for the same information, if it happens to be more efficient to load fresh than walk the existing memory tree
<1> on of the more obvious benefits is for finding a node relative to another node, as the nodes keep relational information but not absolute path info
<0> ya
<1> sorry if my explaination seems a bit airy. i'm finding that not taking the typical UNIX approach leaves me with little common ground to base an explaination on
<0> right. You're better off than me since I only have VFS for external access - my os doesn't use/need a FS at all
<1> ah. i don't really depend on one either. but sometimes files make good abstractions for servers/applications to use. oh and filesystems are useful for storing uh, files in
<0> yes, that's the *nix view
<1> let's call it a personality in this case. the rest of the kernel uses native interfaces to everything
<1> in fact, except for actual volumes, the other file-like interfaces are only wrappers for an object interface
<1> i guess a better description of the subsystem is a hierarchical namespace that volumes can graft into
<0> heh, bjarne stroustrup just joined in on ##c++
<0> alas, no response
<1> i'm glad school is back in session
<1> those two weeks without summer camp or school were rough
<0> why?
<1> kids get used to having a lot to do with school/camp. so working from home to watch 'em and not having as much stimulation makes 'em crazy
<0> time to hit the sack
<0> see ya
<2> I am having a little trouble understanding the format of Device Address Packets for int 13h extensions. I am having the most trouble with the address of transfer buffer field; do I just put the segment in the first word, and the offset in the second?
<3> no idea
<3> hmm
<3> no idea
<4> liar!
<5> hmm. once again, i manage to crash my os with a page fault with something not even remotely related to paging.
<4> use a safe language to write the os
<4> you should help me finish tetra :)
<5> erm
<5> no
<4> which ones?
<5> of course, i only remember stupid ideas :)
<5> like that one where you were going to install your own bios into computers?
<4> huh?
<5> or the one where files in the fs didn't have names?
<4> you know many OSes can be installed into the bios, including linux
<5> duh, that defeats the purpose of a bios ;)
<5> anyway
<4> the bios is old software and not used much by modern oses
<5> true
<5> but how do you expect to multiboot without the bios loading a *standard* sector? :)
<4> you know my filesystem has databases that contain names for files right?
<5> anyway
<5> http://rafb.net/paste/results/HwBzYn31.html - pfs_read_file is page faulting :/
<5> ok, i have to say one more thing though
<5> The language used is very much compiled and not even possible to interpret due to its design.
<5> how are you going to run it if you can't read it? :P
<4> you are right about interpreting it
<4> but whats wrong with compiling it using no optimizations?
<5> air: huh? what do optimizations have to do with it?
<4> and it does support dynamic typing so it can interpret some stuff
<5> i mean, if it's impossible to interpret, how are you going to run it?
<4> what do you mean by run?
<3> he means STFU
<5> air: executing the program (you are going to execute them right? :P
<3> and ESAD
<3> also FYMASYMB
<5> ?
<4> the code is compiled and then executed
<5> no, i didn't mean that at all :P
<5> air: i figured that part out.
<5> define " not even possible to interpret"
<5> btw, you know this will be painfully slow for old computers right?
<4> why?
<5> you're compiling everything locally - think gentoo+openoffice
<4> yes and no
<4> think gentoo GRP
<5> (yes i know about openoffice-bin, i was just trying to think of a huge app)
<1> hi
<4> or whatever that gentoo thing is with three letters similar to GRP :)
<5> air: the precompiled packages?
<3> MOOP
<4> ahhh
<5> yeah, grp
<4> there is your problem
<4> you're thinking brix will have openoffice sized apps
<1> moop?
<5> air: uh, yeah
<4> More Object Oriented Programs
<3> eieio: moop indeed
<1> ohh
<5> say someone writes an app with so many features it's huge like that
<1> lata
<5> object oriented doesn't have to mean smaller...
<4> the whole point behind brix is to do away with large apps
<5> ...
<5> ok, done bashing that for now
<4> everything will be small building blocks
<5> now, back to your fs: WHAT? NO DIRECTORIES?
<4> and that is why its called "brix"
<4> heh
<4> ok
<4> in brix you can only access what you have a reference to
<5> say i take a linux source tarball and extract it
<5> linux source has quite a few directories
<4> different systems objects have references to the files they need access to
<5> where do all the files do?
<5> *go
<4> ok
<5> sounds funky.
<5> what if *i* (the user, i'm not an app) want to open a file?
<4> the program that extracts the tarball would create a special database object that contains directories and named references to each file
<4> so you it dumps the files on the drive and adds another object to track them
<5> ...
<4> you open that object and it acts like a folder window that other oses have
<5> air: so you have something like MFS.
<4> but that is not how brix is meant to work, its only a feature to access legacy crap like that
<5> it's not legacy crap
<5> it's how people think
<4> brix doesnt use a "filesystem" so it is legacy
<5> say i have half a ton of papers scattered on my desk
<5> (***uming the desk is still standing up) how do i find the one about lorem ipsum?
<4> as i was saying before the system components track all their files and there is no way to see those files unless those compoents feel its important to share them with the user
<5> now, if i had a folder containing all the papers about nonsense latin-ish phrases, it'd be way easier to find
<4> the user interface contains databases for each user to hold references to all files the user has access to
<5> air: so basically, you're going the windoze way of hiding a ton of stuff from the user
<5> i own the computer
Return to
#osdev
or
Go to some related
logs:
#netfilter
linux-wlan-ng fc5
#perl
silencer monney
#sendmail
#web
webeleets
+enable accessible login kde
xorp iptables
xorg-x11 7.2 ebuild
|
|