How's your OS 's state?
OSDEV_S
How's yours?
If you have your OS's screenshot, I want show them.
If you don't want show them, don't post it ^^
-S-
Benjamin David Lunt
"OSDEV_S" <dptmr...@naver.com> wrote in message
news:91114277-8b11-47f9...@k19g2000prh.googlegroups.com...
There are quite a few of us here that have projects in many
different stages. Some, just like you, just starting and
some with quite advanced projects. It is interesting
to see everyone's idea on how they have done their project.
Personally, I like the hardware and filesystem part of it,
where others like GUI's, others like processors, etc.
I don't remember, but I think Rod posted a link one time
to a list of OS links.
Rod, did you are was that someone else?
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
http://www.frontiernet.net/~fys/collections.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
Rod Pemberton
news:OXAZl.8$hE...@newsfe13.iad...
>
> I don't remember, but I think Rod posted a link one time
> to a list of OS links.
>
> Rod, did you are was that someone else?
>
Hmm, I don't recall that one offhand... although I might've. Although, I
don't think I did. However, I've posted quite a few messages with links.
RP
Rod Pemberton
news:91114277-8b11-47f9...@k19g2000prh.googlegroups.com...
> How's yours?
It's on hold... I'm working on other personal projects for the time being.
I was going to work on IDE drivers for my OS next, but my old computer
is/was experiencing electrical/power supply issues. I haven't resolved
this. This computer has IDE, but no IDE drives... only SATA. I'm not
interested in risking the new machine by using the old devices in it. I
haven't decided to look at coding SATA drivers yet... I'm still interested
in doing the IDE code next. I've mentioned the exact status, what works,
how it works, etc. a few times in old posts. If you're really interested, I
can locate them. However, they might just be a guide to non-standard OS
design...
RP
Jordi Sanfeliu
Well, that question seems to appear here and in other osdev channels
from time to time.
My current kernel is in the 0.6.1 version, with a great number of
features already included but even greater number of features still
missing. Because it's mainly focused to be educational oriented, that
is not production at all, most of the implemented features don't need
to have the best optimization, but only that they work. I want to
leave enough "room" in the kernel to let people improve it either
individually or grouped.
Currently I'm very excited to start implementing the sys_write()
syscall for the VFS and specially for the EXT2 fs, and once finished
it will probably will be closer to a "self-hosted" OS.
That was my 2 cents (5 cents in my country).
--
Jordi Sanfeliu
James Harris
> "OSDEV_S" <dptmrns...@naver.com> wrote in message
>
> news:91114277-8b11-47f9...@k19g2000prh.googlegroups.com...
>
> > My OS DewLeaf is 2~3 weeks later to release 0.01 ver.(maybe)
> > How's yours?
>
> It's on hold... I'm working on other personal projects for the time being.
>
> I was going to work on IDE drivers for my OS next, but my old computer
> is/was experiencing electrical/power supply issues. I haven't resolved
> this. This computer has IDE, but no IDE drives... only SATA. I'm not
> interested in risking the new machine by using the old devices in it. I
> haven't decided to look at coding SATA drivers yet... I'm still interested
> in doing the IDE code next.
I have a feeling you already answered this but I cannot find the post
in question. In any case the reason might be relevant. Why don't you
buy an old PC on which to develop your OS to replace that dodgy one?
Unless you have some special requirements you could probably find a
second hand one that would be very cheap and have IDE etc (and a
working PSU).
James
Rod Pemberton
news:2d83a551-d54b-488f...@w3g2000yqf.googlegroups.com...
On 16 June, 02:17, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "OSDEV_S" <dptmrns...@naver.com> wrote in message
> news:91114277-8b11-47f9...@k19g2000prh.googlegroups.com...
>
> buy an old PC on which to develop your OS to replace that dodgy one?
The dodgy PC was one of the most reliable/compatible PCs I've ever owned,
which was why I was using it for OS development.
Well, I've got a number of other old PC's. Most are packed away and/or
disassembled. One older one is up and running. Unfortunately, that older
one is a bit too old. I don't think the actual interface is an issue. It
just has very early IDE drives. I'd swap the drives, if I was 100% sure
there wasn't an electrical problem with the dodgy PC's drives... I'm more
like 93%. One PC that is packed away might be fine, but it has a custom
partition apparently used by the BIOS, and I haven't messed around with
installing another OS on it. If I botch up that partition, it might not
boot.
Anyway, I'm (slowly) trying to resurrect that dodgy PC. That's my first
preference. After a few trivial tests, I began suspecting part the power
supply circuitry. So, I bought a cheap new standard 300W ATX power supply.
The old
PC has a miniature 150W power supply design. It has a single power cable
which runs to the motherboard. On the motherboard, there are a bunch of
filter circuits, toroids, and power regulators. From the motherboard, power
supply cables come off and feed power to the drives, fan, etc. (!?!%!#?...)
So, the drives, fan, etc. can be run directly off the new PS' cables. But,
the motherboard has a connector that is different. I've bought a cable with
a similar (hopefully, the same...) connector. So, I need to splice the
connector onto the new PS, or create an adapter cable for the motherboard
connection. I just haven't gotten around doing yet... I'm *really* hoping
the motherboard power doesn't go through that on-board circuitry also. I'm
not sure yet... I'll need to dig out the multimeter first. I think /am
hoping/ this should work.
If not, then I may consider a dual supply setup: new PS driving the drives,
fan, etc. with old PS driving the motherboard. I'm not sure if I can
isolate the two power supplies, or if I need to. I would hope with the
output grounds tied together that the relative logic levels would be fine,
but I don't how the circuits are designed or what they can handle. If there
are absolute ground and logic level differences between the two, tying them
together has the potential for flames, smoke, fried, zapped traces... I'd
most likely dig out the oscilloscope first and watch the combined power for
a fraction of a second to see if there was any immediately obvious issues:
shorted, sagging, spiking.
Or, I might just dig out one of the other PC's since I have to dig the scope
out of the same place...
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:2d83a551-d54b-488f...@w3g2000yqf.googlegroups.com...
> On 16 June, 02:17, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> > "OSDEV_S" <dptmrns...@naver.com> wrote in message
> >news:91114277-8b11-47f9...@k19g2000prh.googlegroups.com...
>
> > Why don't you
> > buy an old PC on which to develop your OS to replace that dodgy one?
>
> The dodgy PC was one of the most reliable/compatible PCs I've ever owned,
> which was why I was using it for OS development.
>
> Well, I've got a number of other old PC's. Most are packed away and/or
> disassembled. One older one is up and running. Unfortunately, that older
> one is a bit too old. I don't think the actual interface is an issue. It
> just has very early IDE drives. I'd swap the drives, if I was 100% sure
> there wasn't an electrical problem with the dodgy PC's drives... I'm more
> like 93%. One PC that is packed away might be fine, but it has a custom
> partition apparently used by the BIOS, and I haven't messed around with
> installing another OS on it. If I botch up that partition, it might not
> boot.
It sounds like you have no floppy boot option - or at least no easy
and safe way to copy the OS from one machine to another.
Maybe it's time to move on, no? You can always archive the old PC and
have a choice to resurrect it as a test but could save a lot of time
by running on something else. In fact you seem to have enough hardware
to make various PCs which could be a bonus as you have a variety of
test hardware. (I presume you will want the finished OS to run on a
variety of hardware but maybe you have other goals.)
>
> Or, I might just dig out one of the other PC's since I have to dig the scope
> out of the same place...
I've thought about buying one or two of the ultra cheap and ultra
small PCs for OS testing. Something like
http://www.viglen.co.uk/recycle/products.htm
http://www.linuxdevices.com/news/NS9843804074.html
http://en.wikipedia.org/wiki/Small_form_factor
I'm not sure how available info on driving the hardware would be but
all the basic chipset stuff should be standard.
Do any of these appeal to you?
James
Rod Pemberton
>
> It sounds like you have no floppy boot option - or at least no easy
> and safe way to copy the OS from one machine to another.
>
The "OS" will fit on a floppy. Test code will fit on a floppy. But, there
is no easy way to get the two compilers I'm using onto the other older PC's.
My "development system" is on two comp's: this one and the dodgy one. I'd
have to pull a harddisk, move to another machine, install, copy, etc.,
replace. IIRC, none of the old PC's have 10Base-T ethernet or USB. I don't
have any USB cards, and my extra (10Base-T) ethernet card is in this machine
due to OS driver issues. I do have some old 10Base-2 cards...
Unfortunately, my dodgy PC has the working CD-burner. The new PC has one,
but it's SATA and the drivers don't support it with this OS. Yeah, I may
have to install Linux to get around that one... So, I've got like, almost
no methods to get large amounts of data onto them, except via floppies or
harddisk.
> Maybe it's time to move on, no?
Of course, ... However, I've already bought a new PS. Also, if I'm going
to put more money into some PC, I'd prefer it be this "new" one, or a new
better one.
> You can always archive the old PC and
> have a choice to resurrect it as a test but could save a lot of time
> by running on something else.
True, but that'd mean I'd need to buy parts for this machine... an internal
IDE harddisk. I'd rather buy an external USB for this one to install
another OS on.
> In fact you seem to have enough hardware
> to make various PCs which could be a bonus as you have a variety of
> test hardware.
Yes, in the future I was hoping to do a small PC test farm. My "OS" is
never going to be a fully functional OS like Windows or Linux. I was hoping
to eventually support the minimal critical hardware and features (harddisk,
keyboard, mouse, text video, etc.) and longest lasting standardized hardware
features of PC's (3.5" floppies, PS/2, IDE, VGA, USB, SATA, etc.).
I have tested my "OS" with different keyboards and mice since that was easy.
Most of the stuff was acquired from '94 to '99 PC's, but some may be older.
I'm kind of missing hardware for '99 to '07. The new PC has proven that USB
2.0 is one I'd like to add to the list. I had many problems with USB 1.0
and pre-USB 1.0... I'll be forced to add SATA to the list, since
IDE is on the way out. Short lived technologies are out (uh, AGP?). Custom
technologies are out (WinModems). Unfortunately, Ethernet would fall into
the custom hardware category, IMO, but they (or a modem) are really
useful... I'm not sure what I intend to do about them. Really old stuff,
like 5 1/4 floppy, parallel port is out, external modems (?), even though I
have the hardware to test against. Even though I've still got serial mice,
I think all of the PC's except the very oldest support PS/2 or had a serial
port card with PS/2 (...unsure...). So, I'm thinking I won't do serial
mice. Basically, I'm thinking there are two basic "generations" of PC's I'd
like to support: IDE with PS/2, and SATA with USB.
> I presume you will want the finished OS to run on a
> variety of hardware but maybe you have other goals.
That was part of the plan. Pull 'em out and test stuff. But, that's a ways
off. Actually, I had planned to give the dodgy one to a relative long
before it's current dodgy status, but I continued using it. The others are
really too old and slow to be useful for even basic Internet web-browsing
due to in-page video like Flash etc. I really wouldn't recommend anything
less than a 500Mhz system for that. Another PC, 450Mhz, is having real
difficulties working with some webpages. Now, if you didn't need Internet
media (video, radio, etc.), the slower PC's are fine.
> I've thought about buying one or two of the ultra cheap and ultra
> small PCs for OS testing.
The linuxdevices article was for an Aewin product:
http://www.aewin.com.tw/
Well, I think I showed some interest a while back. IIRC, I found that these
small PC's were generally underpowered in terms of cpu. I'd want
one that supports a current high-end cpu. The ones you and I have found
seemed destined for embedded "media center" PC's designed to work with a
sound system and projection TV's, or designed for low power use.
The dodgy PC was just compact. It's likely a Mini-ATX motherboard, with two
3.5 bays (1 internal), and one 5.25 bay, plus audio, ethernet, usb, video,
etc. The only problem with the compact dodgy one was I couldn't change out
the video because it was integrated.
Generally, I prefer full PC's with the ability to install various drives.
Even the high end laptops don't have all the features this mid-tower has.
They always skimp on something: memory speed, performance video card, solid
state disk drive, performance cpu. Even if I exclude the SSD, I can't find
one laptop that has _all_ of those features more advanced than this PC,
regardless of the price.
One of the cool things I learned about was "DC to DC ATX PS". Basically,
they split the power supply into two parts: internal and external. The
external part is a DC PS, commonly know as a DC "brick", like the type you
plug into laptops. Internally, they have a DC to DC ATX PS. This takes the
high current fixed voltage DC from the brick and converts it into the
various DC voltages/currents used by the PC. The internal DC to DC ATX PS
can be quite small, as the picoPSU-120 by Mini-Box demonstrates.
DC to DC ATX power supplies
(at least look at the picoPSU-120, first link...)
http://www.mini-box.com
http://www.opussolutions.com
Specialized communications, industrial computing, etc. equipment, e.g., like
Ethernet or USB to serial
http://www.bb-elec.com
Rod Pemberton
James Harris
...
> The "OS" will fit on a floppy. Test code will fit on a floppy. But, there
> is no easy way to get the two compilers I'm using onto the other older PC's.
> My "development system" is on two comp's: this one and the dodgy one. I'd
> have to pull a harddisk, move to another machine, install, copy, etc.,
> replace. IIRC, none of the old PC's have 10Base-T ethernet or USB. I don't
> have any USB cards, and my extra (10Base-T) ethernet card is in this machine
> due to OS driver issues. I do have some old 10Base-2 cards...
> Unfortunately, my dodgy PC has the working CD-burner. The new PC has one,
> but it's SATA and the drivers don't support it with this OS. Yeah, I may
> have to install Linux to get around that one... So, I've got like, almost
> no methods to get large amounts of data onto them, except via floppies or
> harddisk.
I wonder what it would take to run existing compilers and assemblers
on our OSes. Perhaps we'd need to port a clib, be able to load a
standard format such as ELF and support at least some Unix syscalls.
> > Maybe it's time to move on, no?
>
> Of course, ... However, I've already bought a new PS. Also, if I'm going
> to put more money into some PC, I'd prefer it be this "new" one, or a new
> better one.
For about $100 you may be able to get a complete compact base unit. It
should allow boot from USB flash or floppy and have internal PATA -
preferably solid state.
...
> Generally, I prefer full PC's with the ability to install various drives.
> Even the high end laptops don't have all the features this mid-tower has.
> They always skimp on something: memory speed, performance video card, solid
> state disk drive, performance cpu. Even if I exclude the SSD, I can't find
> one laptop that has _all_ of those features more advanced than this PC,
> regardless of the price.
The $100 base unit wouldn't allow pluggable components - at least non-
USB ones. It should be good to get the OS self-sufficient, though.
Then once the OS can run by itself one could look at adapting the OS
to other hardware and bring the chassis-and-cards solution in at that
point.
Of course, maybe you are already beyond that stage. I was thinking the
above as a cheap, simple, and compact way to get an OS up and running.
James
Rod Pemberton
>
> I wonder what it would take to run existing compilers and assemblers
> on our OSes.
Existing...?
Um... By "existing", do you mean "it exists" or do you mean
"full-featured"? Does SmallC qualify as existing? Or, must it be like GCC,
or ANSI C compliant, to qualify as existing?
Well, my choices for C compilers are 1) my in-progress C
(not-C-anytime-soon) compiler, and a DOS port of EV's Linux port of Ron
Cain's SmallC that I've been working on too. The latter is very primitive
C. My next choices, would be, in order:
1) port of Fabrice Bellard's TCC
2) port and/or update of Stephen Johnson's PCC
3) update of LCC v3.6 (last DOS version) with later LCC features added in
4) port of TenDRA C compiler
5) port of de-obfuscated C compiler from IOCCC
> Perhaps we'd need to port a clib
That depends on the dependence of the tools on the C library. I've reworked
much of my utility code to only need a few functions not part of C, such as
file I/O from stdio.h. You can get by without malloc/free... The code
becomes less robust/safe. Typically, I've found that each program needs a
few local replacements for various string.h functions. Rarely, you'll need
ctype.h functions. Other than that, there isn't much need for a C library,
AFAICT. Or, for some reason, I haven't been coding much with the rest of
it...! Well, I was going to mention Steve Dubrovich's CP/M File I/O library
for SmallC as an example of this taken to an extreme. But, it seems his
free webhost pulled his site... :-(
> be able to load a
> standard format such as ELF
Sure. There are many choices here: raw binary like DOS .com, various .obj
formats, NASM's RDOFF, etc. My preference, if I've got to write the tools,
is raw binary. :)
> and support at least some Unix syscalls.
That depends on how the C library is implemented.
- K&R C on PDP-7/11 used 12 system functions
: open, close, read, write, creat, link, fork, exec, wait, exit, lseek,
pipe
- Plauger's "Standard C Library" used 18 system functions
: clock, close, environ, execl, exit, fork, getpid, kill, link, lseek,
open, read, sbrk, signal, time, unlink, wait, write
- RedHat's newlib used 19 system functions
: close, environ, _exit, execve, fork, fstat, getpid, isatty, kill, link,
lseek, open, read, sbrk, stat, times, unlink, wait, write
- Linux v0.01 had 67 syscalls, 13 were unimplemented, 14 were minimal, 40
were complete
I've tried to determine, by visual inspection, the functions the GNU libc
needs to interface with a host OS, but haven't succeeded due to it's size
and complexity. I'd expect GNU libc to use many, many, more functions than
those above.
> Of course, maybe you are already beyond that stage. I was thinking the
> above as a cheap, simple, and compact way to get an OS up and running.
Oh, my OS runs. It starts from DOS via a special TSR. It has a text
screen, mouse, keyboard. I wanted harddisk support next. You know. The
basics. Well, the basics of an OS ... IMO. ;-) Some people don't consider
DOS or FORTH as being an OS, and don't consider a C64 as having an OS. They
define an OS as something more powerful, and developed later. Originally, I
was planning on IDE code next, then floppy, cdrom very last. With this
machine, I guess I should consider SATA, floppy, USB, then cdrom, or buying
a small IDE - if my PS hacks on the dodgy PC don't work. Actually, in my
mental list, I had added in a "filesystem" after the IDE code. But, I'm
diverted to my other projects for a while.
Rod Pemberton
James Harris
...
> > I wonder what it would take to run existing compilers and assemblers
> > on our OSes.
>
> Existing...?
>
> Um... By "existing", do you mean "it exists" or do you mean
> "full-featured"? Does SmallC qualify as existing? Or, must it be like GCC,
> or ANSI C compliant, to qualify as existing?
I was thinking of your comment: "But, there is no easy way to get the
two compilers I'm using onto the other older PC's." If you are writing
your own compiler that changes the issue.
...
> > be able to load a
> > standard format such as ELF
>
> Sure. There are many choices here: raw binary like DOS .com, various .obj
> formats, NASM's RDOFF, etc. My preference, if I've got to write the tools,
> is raw binary. :)
Using only your preferred unsigned ints no doubt. ;-)
...
> > Of course, maybe you are already beyond that stage. I was thinking the
> > above as a cheap, simple, and compact way to get an OS up and running.
>
> Oh, my OS runs. It starts from DOS via a special TSR. It has a text
> screen, mouse, keyboard.
In referring to using a low powered PC I was thinking of you booting
your OS and running on the bare metal. Unless you use DOS services it
sounds like you are just about there anyway.
> I wanted harddisk support next. You know. The
> basics. Well, the basics of an OS ... IMO. ;-) Some people don't consider
> DOS or FORTH as being an OS, and don't consider a C64 as having an OS. They
> define an OS as something more powerful, and developed later. Originally, I
> was planning on IDE code next, then floppy, cdrom very last. With this
> machine, I guess I should consider SATA, floppy, USB, then cdrom, or buying
> a small IDE - if my PS hacks on the dodgy PC don't work. Actually, in my
> mental list, I had added in a "filesystem" after the IDE code. But, I'm
> diverted to my other projects for a while.
OK
James
Rod Pemberton
On 1 July, 20:56, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> If you are writing
> your own compiler that changes the issue.
>
I'm somewhat opposed to interpreters. I love their interactiveness. I'm
opposed to them, in large part, because they are slow. In essence, they
reimplement a virtual cpu and virtual instruction set in software. This
bypasses the optimal use of the hardware: native instructions. And, my own
interpreters and experiements with them are also slow relative to compiled
code. That's part of why I was using compiled C. C compilers produce are
good with optimization and generate good, fast assembly. But, 1) now that I
have a 64-bit cpu not using 64-bit mode, and 2) code developed on two C
compilers that will likely never be 64-bit capable, I've been casually
considering an interpreter. There's a chance my codebase will never make it
to 64-bits or beyond... Unfortunately, I'd say C isn't well suited to
interpretation. The other option is to primitize the codebase so that very
simple C compilers can be extended to 64-bits.
> > Of course, maybe you are already beyond that stage. I was thinking the
> > above as a cheap, simple, and compact way to get an OS up and running.
>
> > Oh, my OS runs. It starts from DOS via a special TSR. It has a text
> > screen, mouse, keyboard.
>
> In referring to using a low powered PC I was thinking of you booting
> your OS and running on the bare metal. Unless you use DOS services it
> sounds like you are just about there anyway.
It's on bare metal. It just starts from DOS.
Fortunately or unfortunately, I skipped the normal boot from a bootloader
process. This was because I wasn't developing an OS, at first. I was just
wanting a method to have a single DOS DPMI host common to both C compilers I
was using. In search of that method, I fell into developing my own OS, and
bypassed this stage of OS development.
Very roughly, the DOS executable loader loads a DPMI application, part of
which is my OS. A DPMI application can be thought of as having three parts:
16-bit DOS executable code, plus code to load a 32-bit DPMI host, plus
32-bit application code. That might not be an exact description... Anyway,
I didn't need or want the DPMI host, or DOS environment for that matter. I
just needed the 32-bit application code, my OS, in memory, at a known
location, and setup to run. I then "unload" the DPMI host leaving me with
execution control in my TSR. The TSR switches back into my OS. Obviously,
the OS has to be free of DPMI, DOS, BIOS, etc. calls.
So, basically, I've used DOS itself as my bootloader, a DOS .exe as my file
format - instead of ELF etc., the DOS exec loader as my OS loader, DOS C
compilers as my development system. It works. But, if you starting
developing an OS as your original choice instead of via some other path, I
wouldn't recommend using this startup method. I thought it was nifty
though. Using this method and DOS allowed me to jump right into developing
my OS code without also writing a bootloader etc. I'll rework it eventually
for a normal bootloader. I've got some of that done for one C compiler.
However, I'm moving away from both of them towards simpler and user
enhanceable compilers...
I am using parts of the C library in my OS. While the calls I'm using are
free of DPMI, DOS, BIOS calls, they weren't free of bugs. That's when I
realized I may need control of a C compiler to control the development of my
OS. Eventually, I probably should rework the OS to only use as little as
possible of the C library, as I did for my utilities. That would lessen the
impact of the C library on the OS.
Rod Pemberton
Rod Pemberton
On 1 July, 20:56, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> >
> > My preference, if I've got to write the tools,
> > is raw binary. :)
>
> Using only your preferred unsigned ints no doubt. ;-)
>
Of course, ... :-)
Why would anyone ever use signed? ;-)
AFAICT, their use only leads to errors. They're a frequent source of errors
in loops and counters. If -1 is represented as 0xFFFF for a 16-bit
compiler, is the 8-bit value 0xFF also -1 via sign preserving promotion to
16-bits? etc.
Take this C code that was very recently posted to clax86:
unsigned BitSize(long long Data) { unsigned Size = 0; while (Data)
{ Data >>= 1; Size ++; } return Size; }
Do you see or suspect an error?
What does C do to the binary representation of a signed value due to a
bitwise rightshift?
First, before I tell why I suspect signed as a problem in his code, I must
say a few things about using signed values in C. I don't know. I don't
care. I generally don't use them. And, I can look up proper operation if I
ever need to.
Use of signed, instead of unsigned, is a "red flag" for me. I suspect an
infinite loop due to the signed value Data and the bitwise rightshift
operator. Let's say we are using 8-bit _signed_ value to simplify the
numbers. If I have -2, and a bitwise rightshift by one is performed, -2 >>
1, I'd expect a value of -1. Let's look at that in binary using hex for the
resulting bit patterns. If -2 is 0x82 in hex, and we bitwise rightshift it,
do we end up with 0x41 or 0x81? i.e., 65 or -1? 65 certainly isn't
expected. It preserves the bit pattern of a rightshift on 8-bits. It fails
to preserve the sign. -1 is expected. It preserves the sign. It fails to
preserve the bit pattern of a rightshift on 8-bits. However, it does so
correctly for 7-bits. The resulting value depends entirely on how the
bitwise rightshift operates on signed value. Unfortunately, preserving the
sign _could_ cause an infinite loop. e.g., if the rightshift operator is
sign preserving: -2 (0x82), -1 (0x81), -0 (0x80). i.e., -0 (0x80) never
becomes +0 (0x00), without help behind the scenes...
So, why use signed? Why use signed when it leads to errors or uncertainty?
Why use signed if unsigned will do the same job?
Yes, I'm thoroughly aware that GCC optimizes a 32-bit signed "int" far
better than 32-bit "unsigned long". That's about the only case where I've
intentionally used them.
Rod Pemberton
s_dub...@yahoo.com
> "James Harris" <james.harri...@googlemail.com> wrote in message
Reconstituted until next time... http://www.project-fbin.hostoi.com/index.htm
A little new, Call5 can be used from .EXE's if the EXE header is made
to be the same size as the PSP, 0100h bytes. I think I need to
explain this better in the webpage:
http://www.project-fbin.hostoi.com/nasmhints/binspace/binexe/bin_exe.html
Steve
It is an interesting perennial discussion as to what an OS is, and
what it should provide. As for me, I take a minimalistic view, for
practical reasons - I don't have enough man years left in me. As I
look at it, at the core of an OS is the Loader, a simple thing that
dictates the rest of the OS strategy, mostly Flat memory usage as I
look around. But why? -Because of the tools mostly, I think. The
tools don't support thinking in terms of multi-sectioned code very
well. I'm thinking a little forethought here would save complexity
later, I'll see when I pull together all my 'proof of concept' code
into some coherent whole whether it meets some definition of an OS.
s.
Rod Pemberton
news:ecf14ced-7daa-499d...@q11g2000yqi.googlegroups.com...
On Jul 1, 2:56 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> Reconstituted until next time...
http://www.project-fbin.hostoi.com/index.htm
>
> A little new, Call5 can be used from .EXE's if the EXE header is made
> to be the same size as the PSP, 0100h bytes. I think I need to
> explain this better in the webpage:
> http://www.project-fbin.hostoi.com/nasmhints/binspace/binexe/bin_exe.html
Ah... Thinking about compiling DrAcOnUx's Linux v0.01-remake to run
natively on, er... under, XP, are we? LinuXP? :-)
http://draconux.free.fr/os_dev/linux0.01_download.html
Just kidding, but may I surmise that there is something you really, really,
really, want to compile and run on XP?...
If you can use the Call5 interface from a .EXE in XP, then you could setup a
small OS-like application. IIRC, file I/O and text... There other small
OSes with source. I know of a few, but I only have links for these:
Paul Edwards PDOS (Public Domain, DOS-like)
http://sourceforge.net/projects/pdos/
Wild Boar Scafa (small microkernel)
http://users.evtek.fi/~tk/
> It is an interesting perennial discussion as to what an OS is, and
> what it should provide. As for me, I take a minimalistic view, for
> practical reasons - I don't have enough man years left in me.
:)
RP
s_dub...@yahoo.com
> <s_dubrov...@yahoo.com> wrote in message
>
> news:ecf14ced-7daa-499d...@q11g2000yqi.googlegroups.com...
> On Jul 1, 2:56 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> > Reconstituted until next time...
>
> http://www.project-fbin.hostoi.com/index.htm
>
>
>
> > A little new, Call5 can be used from .EXE's if the EXE header is made
> > to be the same size as the PSP, 0100h bytes. I think I need to
> > explain this better in the webpage:
>
> Ah... Thinking about compiling DrAcOnUx's Linux v0.01-remake to run
>
> Just kidding, but may I surmise that there is something you really, really,
> really, want to compile and run on XP?...
Well, small-c & Call5 > 64k maybe. There's a convenience factor of
using XP for me, Call5 allows me to postpone the filesystem for a
time, until the other parts are fitting together better.
Steve
>
> If you can use the Call5 interface from a .EXE in XP, then you could setup a
> small OS-like application. IIRC, file I/O and text... There other small
> OSes with source. I know of a few, but I only have links for these:
>
> Paul Edwards PDOS (Public Domain, DOS-like)http://sourceforge.net/projects/pdos/
>
> Wild Boar Scafa (small microkernel)http://users.evtek.fi/~tk/
Rod Pemberton
news:6d912824-85ac-4a44...@b14g2000yqd.googlegroups.com...
> On Jul 5, 5:46 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > <s_dubrov...@yahoo.com> wrote in message
> >
news:ecf14ced-7daa-499d...@q11g2000yqi.googlegroups.com...
> > On Jul 1, 2:56 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> >
> > > A little new, Call5 can be used from .EXE's if the EXE header is made
> > > to be the same size as the PSP, 0100h bytes. I think I need to
> > > explain this better in the webpage:
> >
>http://www.project-fbin.hostoi.com/nasmhints/binspace/binexe/bin_exe....
> >
> > Ah... Thinking about compiling DrAcOnUx's Linux v0.01-remake to run
> > natively on, er... under, XP, are we? LinuXP?
:-)http://draconux.free.fr/os_dev/linux0.01_download.html
> >
> > Just kidding, but may I surmise that there is something you really,
really,
> > really, want to compile and run on XP?...
>
Uh, you were supposed to say CP/M... See, I say Linux... Sigh. ;)
> Well, small-c & Call5 > 64k maybe. There's a convenience factor of
> using XP for me, Call5 allows me to postpone the filesystem for a
> time, until the other parts are fitting together better.
Well, let me know when you get CP/M, or whatever, to run on XP...
Rod Pemberton
Marven Lee
I haven't been working on my OS for quite some time. If I do
continue with it then I'll need to do major changes to my VFS and
device driver interfaces.
My OS, Kielder OS can be found at
http://web.bethere.co.uk/kielder/osdev.html
A bit about my OS.
I guess it is a modular monolithic kernel with some basic
drivers for hard drive and cd-rom and filesystem handlers
for FAT (no lfn) and iso9660 (no extensions). The drivers
are usually threaded and use message passing
but all run inside the kernel. I'd say it is a mixture of
Unix user-api and Amiga-like in kernel features such
as message passing and device driver model.
Applications are single threaded, but the kernel runs
many threads, usually a thread for each driver.
Like I said, the user API is mostly Unix-like, I didn't want to
implement fork/exec and unix signals but eventually needed
to so that shells could be ported. I ported KSH, I couldn't
get BASH to compile in the early days but maybe it could
now that I've added a lot more functions to my library.
I use Newlib as my library but added quite a few other
functions to get GNU coreutils and other stuff to compile.
I created cross compilers with i386-kielder-elf targets
by looking at the config files and copying what other OSes
do.
From the user's point of view the root directory only holds
mount points for filesytems, character devices and "assign"
aliases.
The root directory looks something like...
/cd0/
/fd0/
/hd0/
/sys/
/null/
/pipe/
cd0, hd0 & fd0 are mount points and are handled by filesystem handler
code.
"sys" is an alias to the boot device, usually hd0
"null" is a null mount, like "/dev/null" in Unix
"pipe" appears in the list but is normally accessed by pipe() syscall.
So it's a bit Amiga-like.
Inside the kernel there is a 256-priority round robin scheduler, interrupts
are handled in a nested fashion, a seperate interrupt stack is used to
handle nested interrupts in case there is a need to use large stacks in
interrupt handlers. I might have removed/commented out this code
though (can't remember).
There is message passing within the kernel, usually between filesystem
and drivers. Message passing is similar to that on AmigaOS, with
message ports and non blocking putmsg(), getmsg(). There are
signals inside the kernel used to notify a task of some event such
as messages arriving at a message port, again based on AmigaOS,
with signal(), wait() and waitport(). These signals aren't asynchronous
like Unix signals, you have to wait() to receive and clear pending
signals.
There is also a few other synchronization primitives, mutexes,
rwlocks and condition variables.
There are device drivers and filesystem handlers. Again, based on
AmigaOS.
Mount points are organised as...
mount --> filesystem handler --> device driver
(hd0) fat.handler ata.device
The list of mounts is maintained by a thin layer of code in the
kernel, sort of a VFS. filesystem handlers handle read, write,
open, mkdir, etc functions. Usually the filesystem handlers
manage their own small caches.
device drivers usually read or write to disk in blocks.
The interface is again very similar to AmigaOS, with
OpenDevice(), CloseDevice(), BeginIO() and AbortIO()
being the main interfaces to both handlers and drivers.
There is no plug n play or PCI support at the moment,
so a basic initialization scheme is used. Sort of based on
the Amiga's romtag/ boot node stuff.
Device drivers are initialized and determine which units
it can find. It then informs the VFS-like code of each
unit and which filesystem-handler to use for each unit
found.
Once all handlers and devices are initialized the
The VFS creates the mount structures, fills them
in and opens the appropriate filesystem-handlers that
in turn opens the corresponding device driver.
Device drivers read and write data from user-space
using CopyIn (as, dst, src, nbytes), CopyInStr() and
CopyOut(). They take a pointer to an Address Space
structure as an argument. The pointer is passed to
handlers and drivers in a IORequest message along
with command, other fields and pointer to data in
user-space.
Bad Points and future development
-------------------------------------
KSH, coreutils, elvis and a few other things have
been ported. I managed to compile GCC and
binutils, they ran on the OS but didn't compile
probably due to limited filenames of FAT 8.3
as well as dummy functions for sysconf(),
pathconf() and others.
I had problems with my ATAPI Identify() code
creating an extra interrupt, never sorted that
out fully.
I really want to rewrite the filesystem and device
driver code. I do like the Amiga style message
passing and BeginIO() interface. but want better
device detection and removal code. At present
the link between filesystem handler and device
driver is only created at initialization time, there
is no way to remove media and insert new media
with a different filesystem into a device. Really
want a nice PnP interface to handle this kind of
thing but need a major change of code.
Also current directory is implemented as a string
held by the process structure. Really want to
handle the current directory using a file descriptor
so that fchdir() can be implemented. getcwd()
currently just reads the string from the process
structure. Only when I read what Unix OSes
do did I realise that they ascend the directory
tree and check inode/dev numbers to build
up a string of the current directory.
I would like a global cache as well instead of
the cache per filesystem.
I've got some ideas how all this could be done,
but would take a while, lots to do and not sure
when I'll get back to doing it.
--
Marv
Rod Pemberton
news:7buaddF...@mid.individual.net...
>
> device drivers usually read or write to disk in blocks.
>
> The interface is again very similar to AmigaOS, with
> OpenDevice(), CloseDevice(), BeginIO() and AbortIO()
> being the main interfaces to both handlers and drivers.
> Device drivers read and write data from user-space
> using CopyIn (as, dst, src, nbytes), CopyInStr() and
> CopyOut(). They take a pointer to an Address Space
> structure as an argument. The pointer is passed to
> handlers and drivers in a IORequest message along
> with command, other fields and pointer to data in
> user-space.
>
Is the data moving directly to/from device to the user-space? Or, is the
data being copied/moved twice? I.e., from device to driver-space to
user-space or the reverse?
It looks like "open", "close", "read", "write", "lseek", "link" and/or
"unlink" and/or "creat" are the minimum operations for a *nix or C based
file I/O library. "ioctl" isn't mentioned by those listed below either.
That seems sufficient enough for file I/O, but, are those complete enough
for a filesystem? There are no directory functions. Doug Gwyn's PD libndir
package implements 4.2BSD functions "opendir", "readdir", "telldir",
"seekdir", and "closedir" for directory access. But, are these the most
harmonious functions for a typical filesystem?
- K&R C on PDP-7/11 used 12 system functions
: open, close, read, write, creat, link, fork, exec, wait, exit, lseek,
pipe
- Plauger's "Standard C Library" used 18 system functions
: clock, close, environ, execl, exit, fork, getpid, kill, link, lseek,
open, read, sbrk, signal, time, unlink, wait, write
- RedHat's newlib used 19 system functions
: close, environ, _exit, execve, fork, fstat, getpid, isatty, kill, link,
lseek, open, read, sbrk, stat, times, unlink, wait, write
> I had problems with my ATAPI Identify() code
> creating an extra interrupt, never sorted that
> out fully.
>
Yeah, I remember that...
> I really want to rewrite the filesystem and device
> driver code. I do like the Amiga style message
> passing and BeginIO() interface. but want better
> device detection and removal code. At present
> the link between filesystem handler and device
> driver is only created at initialization time, there
> is no way to remove media and insert new media
> with a different filesystem into a device. Really
> want a nice PnP interface to handle this kind of
> thing but need a major change of code.
> [...]
> Also current directory is implemented as a string
> held by the process structure. Really want to
> handle the current directory using a file descriptor
> so that fchdir() can be implemented. getcwd()
> currently just reads the string from the process
> structure. Only when I read what Unix OSes
> do did I realise that they ascend the directory
> tree and check inode/dev numbers to build
> up a string of the current directory.
>
Well, I suspect Ben Lunt is our resident filesystem expert... It seems he's
looked at and implemented the most. Unfortunately, I haven't seen him
partake in recent filesystem conversations, or mention the merits or design
problems of the ones he's interested in. Maybe I should search for old
posts.
Personally, I have an idea of what I'd like in a filesystem, and problems I
don't want from filesystems I've used. As I worked through some of those
issues mentally, my simple filesystem became quite complicated rather
quickly... :( I'm not interested in writing a full database and DBMS
system to have a filesystem. There were a few conversations a while back
where a few of us discussed our visions of filesystems.
Rod Pemberton
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:h3e3as$5u6$1...@aioe.org...
>
> Well, I suspect Ben Lunt is our resident filesystem expert... It seems
> he's
> looked at and implemented the most. Unfortunately, I haven't seen him
> partake in recent filesystem conversations, or mention the merits or
> design
> problems of the ones he's interested in. Maybe I should search for old
> posts.
Hi guys,
Sorry, I have been quite busy lately, and have had to pick and choose
which messages to respond to. However, I will do my best to discuss
the pro's and con's (my opinions only) of each file system that I
have seen.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
FAT:
Pro's:
- Widely available, simple, easy to implement.
- Easy to get/create volume images to test your driver with
Con's:
- Patented.
- 8.3 style names unless you use LFN's
- No extended attributes
There is a Linux patch that allows a user to write a FAT system that
gets around the patent. The patent states that the FAT lfn is a
short file name entry preceded by the long file name entry(s). The
way that Linux has gotten around this is not to have one or the other.
If you have a file name that is 8.3 or less, just use the short file
name entry and not the lfn entry. If you have a file name longer
than 8.3, then you must use the lfn entry. However, to make it
valid you still have to have the short file name entry. Linux
has gotten around this by placing garbage as the short file name
entry, but the garbage has a format to it. It still has what it
needs to denote a long file name exists, but it doesn't have the
short file name. It also has data to make sure that an OS doesn't
see it as a bad entry and delete it.
See more at:
http://lkml.org/lkml/2009/6/26/313
FAT also doesn't have much security for damaged sectors. If the
boot sector is lost, the volume is lost. There are ways to guess
what type of FAT system it is, but most likely, the volume is
lost.
FAT32 is actually FAT24. FAT32 only uses 24 bits. Therefore
can only access 16 Million clusters. If each cluster is 32k in
size (the specs say that you can not have more than 32k), then
you only have about 550 gigabytes per volume (if my calculations
are correct).
- I have implemented all but the "patent bending" code for my
file system driver.
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
FYSFS: (http://www.frontiernet.net/~fys/fysfs.htm)
This is a file system of my own doings. I wrote it to verify
that my kernel was completely FS independent. It has some
pro's, but definitely has some con's:
Pro's:
- Fairly simple to implement
- Well documented and has examples
- Large files, filenames, volumes
- Less disk access than FAT
Con's:
- Each file entry must allocation disk space in 128 byte chunks
- No extended attributes
- Not very fast
- Not much, though some security against volume corruption.
This FS allows for 4.8 yottabyte volumes. A yottabyte is a
terabyte of terabytes. This FS allows unlimited filename sizes,
only limited to the OS being used.
However, this FS still uses the FAT style allocation.
- I have implemented most everything for this FS into my
file system driver.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
LeanFS: (http://freedos-32.sourceforge.net/doc/lean.html)
This is a FS that Salvatore ISAJA has been working on (a while ago)
with a little input from my suggestions. It has some similarities
to the EXT2 file system.
Pro's:
- Allows for large disks.
- Has fairly quick allocation units
- Has some security for volume corruption
- Has (will have) extended attributes
Con's:
- Similar to Ext2, so why not use Ext2?
- Not at all widely used, though may be used with FreeDOS32 in
the near future.
- Not easy to get/create volume images to test your driver with
I like this FS. It has a lot of nice features. It is simple enough
to implement, but detailed enough to use in mainstream applications.
- I have implemented most everything for this FS plus a few extras
that should be added to the specs, into my file system driver.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ext2/3/4:
Linux uses this FS as it's main FS, though may be soon moving
to the BtrFS (http://btrfs.wiki.kernel.org/index.php/Btrfs_design).
Pro's:
- Widely used in the Linux world.
- Has fairly quick allocation units
- Has security for volume corruption (a journal)
- Has extended attributes
- Allows for large volumes
- Journalled FS.
Con's:
- Ext3 is simply the addition of a few items to Ext2 mainly
the Journal.
- Ext4 has quite a few new features but tries to stay backward
compatible to Ext2/3. This makes it somewhat difficult to
implement correctly.
- Not easy to get/create volume images to test your driver with
- I have implemented most everything for the Ext2 FS, and Ext4 FS,
though I do not have a Journal coded.
http://ext4.wiki.kernel.org/index.php/Main_Page
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
HPFS:
This FS may have been two different FS's, one for MS's OS/2
and early NT's and one for Apple. I don't know if they were/are
the same. I don't know much about either FS, other than it
does have Band's like LeanFS above.
- I have very little code implemented for this FS.
http://www.warpspeed.com.au/Products/OS2/GU/Manual/toc.htm
http://www.warpspeed.com.au/Products/OS2/GU/Manual/appg.htm
http://www.warpspeed.com.au/Products/OS2/GU/Manual/appi.htm
http://www.howzatt.demon.co.uk/articles/06may93.html
http://www.nondot.org/sabre/os/files/FileSystems/HPFS/index.html
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ISO (9660):
This FS is used for read only optical disks and may be obsolete.
It has some drawbacks, which include short file names unless you
use some extensions. Also, very few nested directories, unless
you use the extensions. I don't know too much about this FS,
nor have I implemented it too much. Simply a read only driver.
http://alumnus.caltech.edu/~pje/iso9660.html
http://en.wikipedia.org/wiki/ISO_9660
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ISO (Joliet)
I don't know if I know anything about this FS (smile).
http://pagesperso-orange.fr/pierrelib/filesystems/joliet_spec_v1.html
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
NTFS:
Microsoft's modern FS. There use to not be much documentation about
this FS at all, then some people at Linux decided to create a
driver for it and supplied information about it.
(http://www.linux-ntfs.org/doku.php)
I don't know much, nor have implemented much of this FS. I do
have a read only implementation, but it takes for every to read
the directories. I haven't spent too much time finding out why :-)
http://www.linux-ntfs.org/doku.php
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Reiser FS
This FS used a technique that would allow quick and use very little
space for small files. However, since the author has been (allegedly)
convicted of murdering his wife, no one wants to touch it.
In fact, the website http://www.namesys.com/ even has been removed.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
XFS:
http://oss.sgi.com/projects/xfs/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
AncientFS
http://osxbook.com/software/ancientfs/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Notes:
More information on FAT, HPFS, and NTFS pros and cons:
http://support.microsoft.com/kb/q100108/
Many other FS's listed:
http://en.wikipedia.org/wiki/List_of_file_systems
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I guess the main reason I like FS's, is that I like to take
a file system spec and a volume image of that FS and see if
I can write code to retrieve data from that image. Anyway,
I hope this helps you in your FS search.
Please note that the above information is simply my opinion
and the facts may or may not be correct. For assurance,
see the links that I have included with each FS.
Enjoy,
Marven Lee
Rod Pemberton wrote:
> Marven Lee wrote:
>> device drivers usually read or write to disk in blocks.
>>
>> The interface is again very similar to AmigaOS, with
>> OpenDevice(), CloseDevice(), BeginIO() and AbortIO()
>> being the main interfaces to both handlers and drivers.
>> [...]
>> Device drivers read and write data from user-space
>> using CopyIn (as, dst, src, nbytes), CopyInStr() and
>> CopyOut(). They take a pointer to an Address Space
>> structure as an argument. The pointer is passed to
>> handlers and drivers in a IORequest message along
>> with command, other fields and pointer to data in
>> user-space.
>>
>
> Is the data moving directly to/from device to the user-space? Or, is the
> data being copied/moved twice? I.e., from device to driver-space to
> user-space or the reverse?
The data is usually copied once, from user space to a cache managed
by a filesystem handler inside the kernel. The driver can then read from
the cache directly. I read from the cache and do PIO in my ATA drivers
as I don't have DMA modes yet. The floppy driver does a second copy
into it's own ISA DMA buffer.
> It looks like "open", "close", "read", "write", "lseek", "link" and/or
> "unlink" and/or "creat" are the minimum operations for a *nix or C based
> file I/O library. "ioctl" isn't mentioned by those listed below either.
> That seems sufficient enough for file I/O, but, are those complete enough
> for a filesystem? There are no directory functions. Doug Gwyn's PD
> libndir
> package implements 4.2BSD functions "opendir", "readdir", "telldir",
> "seekdir", and "closedir" for directory access. But, are these the most
> harmonious functions for a typical filesystem?
[..]
> - RedHat's newlib used 19 system functions
> : close, environ, _exit, execve, fork, fstat, getpid, isatty, kill, link,
> lseek, open, read, sbrk, stat, times, unlink, wait, write
I use Newlib, but I had to add quite a few extra functions to get
KSH and GNU coreutils to compile. A lot were dummys, such
as sysconf(). and other ..conf() functions. I've added a list of the
filesystem related calls in my kernel's system call table below, it takes
up the bulk of the system calls implemented. In addition there
are a few more dummy functions I added to Newlib.
Calls such as getcwd() are implemented in user-space in most systems,
but as I think I mentioned, I keep a string of the current directory
in my kernel, though I intend to replace it with a filehandle and do
getcwd() in user-space.
I guess some calls such as stat and fstat could be implemented with
one calling the other, such as stat calling open, fstat, close, along
with some extra error checking.
.long SetPGRP / program-group functions, don't implement
.long GetPGRP / sessions, only groups.
.long Sysconf
.long Mount / manual mounting of a device
.long Unmount
.long Open
.long Close
.long Link
.long Unlink
.long Symlink
.long Readlink
.long Mkdir
.long Mkfifo
.long Pipe
.long Fcntl
.long Dup
.long Dup2
.long Rename
.long Ftruncate
.long Truncate
.long Fstat
.long Stat
.long Lstat
.long Isatty
.long Sync
.long Fsync
.long Read
.long Write
.long Seek
.lonf Getcwd
.long Chdir
.long Fchdir / FIX: Current dir currently stored as path string, not
fd
.long Chroot / Might add it, might not
.long Rmdir
.long Opendir
.long Closedir
.long Readdir
.long Rewinddir
.long Fpathconf
.long Pathconf
.long Ioctl
.long Umask
.long Chmod
.long Chown
.long Tcgetattr
.long Tcsetattr
.long Tcsetpgrp
.long Tcgetpgrp
.long GetUID
.long SetUID
.long GetEUID
.long GetGID
.long SetGID
.long GetEGID
--
Marv
Maxim S. Shatskih
On Windows, yes. Windows keeps name and handle of the current dir in the process's PEB and automatically provides this handle as related handle to NtCreateFile if CreateFile is called with relative path.
On any popular UNIX, no.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Marven Lee
Maxim S. Shatskih wrote:
> Marven Lee wrote:
>> Calls such as getcwd() are implemented in user-space in most systems,
>
> On Windows, yes. Windows keeps name and handle of the current dir
> in the process's PEB and automatically provides this handle as related
> handle to NtCreateFile if CreateFile is called with relative path.
>
> On any popular UNIX, no.
Just had a quick search and seems that some Unix OSes used to
crawl the directory tree towards root in user space, reading through
each directory and comparing the dev and inode numbers to see if
they match the child directory it ascended from. Then add the matching
pathname of the directory to a buffer and continue ascending. Finally
flipping the order of the buffer so the path starts from root.
Seems Netbsd went to an in-kernel implementation sometime around
1999 where it looks like they cached or added the filename to vnodes.
I guess Linux and other OSes did something similar before then.
I'm not sure what Minix does.
I imagine user-mode getcwd() could fail if the user didn't have
permission to read one of the directories in the path.
--
Marv
Maxim S. Shatskih
>
> Just had a quick search and seems that some Unix OSes used to
> crawl the directory tree towards root in user space, reading through
> each directory and comparing the dev and inode numbers to see if
> they match the child directory it ascended from. Then add the matching
> pathname of the directory to a buffer and continue ascending. Finally
> flipping the order of the buffer so the path starts from root.
And how chroot() will work for this case?
> I guess Linux and other OSes did something similar before then.
In Linux of old times (2000 or so), current dir vnode was kept in the process structure. getcwd() did a slow ascension, but in kernel mode.
Windows keeps both the string name (for getcwd) and the handle in user mode's process environment block (which is cloned to the child process), and, for all file syscalls, passes the handle as "related file object".
The kernel knows nothing on current directory, it only knows the relative file pathnames.
This kind of the directory handle is very similar to the one opened for directory reading by FindFirstFile.