headers
Niels Reedijk | 8 Aug 2004 20:55
Picon

Weird KDL USB Stack

Hi,

I've recently switched development machines (again). On my new machine,
everytime I load the usb stack I get thrown into kdl. I have a driver that
loads the stack in the open hook. However, in the file usb.cpp in the bus
manager, I enter kdl. I believe it's in the "new Stack()" instruction. The
address is, strangely, 00000000 (unmapped memory). Anyone knows what it is
caused by? It seriously hinders some functionality I'd like to test.

Niels Sascha Reedijk

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
Permalink | Reply | 0 comments |
headers
Mat Hounsell | 9 Aug 2004 06:01
Picon

Weird KDL USB Stack

> I've recently switched development machines (again). On my new machine,
> everytime I load the usb stack I get thrown into kdl. I have a driver that
> loads the stack in the open hook. However, in the file usb.cpp in the bus
> manager, I enter kdl. I believe it's in the "new Stack()" instruction. The
> address is, strangely, 00000000 (unmapped memory). Anyone knows what it is
> caused by? It seriously hinders some functionality I'd like to test.
> 
> Niels Sascha Reedijk
> 

When I was working we were developing for an OS/Compiler that didn't support
exceptions. Their new(void) operator returned NULL (00000000) when out of
memory. The tech lead thought this was the correct way.

We were developing on Unix with GCC.

The C++ standard states that the new operator MUST throw an exception if it can
not allocate memory. When developing testing for memory handling we overloaded
new(void) to return NULL. All the tests seg-faulted (KDL) during construction
as  GCC didn't check for null before attempting construction and this so 'this'
was NULL; a guaranteed chrash.

The solution is simple and standard; change calls to new(void) to
new(std::nothrow_t const & const).

For Example

    WRONG :
        A * a = new A();
        if( a != 0 ) { do_stuff() }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Weinhold | 28 Aug 2004 23:02
Picon

VFS syscall and syscall mechanism changes

Howdy,

I just committed several changes to the VFS syscalls and the syscall 
mechanism in general. The former were needed for the Storage Kit, while the 
latter simplify the syscall maintainance process.

Formerly one had to manually change ksyscalls.h, syscalls.S and syscalls.c 
when adding/removing/changing syscalls. A rather boring and error prone 
work. Now the stuff is automatically generated from the syscall prototypes 
defined in syscalls.h, at the cost of providing names for all prototype 
parameters and keeping the syscall name and the name of the respective 
kernel function consistent (_kern_XYZ() and _user_XYZ()).

Some oddities remain (cf. syscalls.c), for instance that the syscall 
_kern_exit() was (and still is) mapped to _user_exit_thread(), or that the 
parameters of _kern_spawn_thread() and _user_spawn_thread() as well as 
those of _kern_wait_for_team() and _user_wait_for_team() are not 
consistent. To those in the know, please have a look at this.

CU, Ingo

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 7 comments |
headers
Axel Dörfler | 29 Aug 2004 04:40
Picon

Re: VFS syscall and syscall mechanism changes

Ingo Weinhold <bonefish@...> wrote:
> I just committed several changes to the VFS syscalls and the syscall 
> mechanism in general. The former were needed for the Storage Kit, 
> while the 
> latter simplify the syscall maintainance process.

Great! :-)

> Formerly one had to manually change ksyscalls.h, syscalls.S and 
> syscalls.c 
> when adding/removing/changing syscalls. A rather boring and error 
> prone 
> work. Now the stuff is automatically generated from the syscall 
> prototypes 
> defined in syscalls.h, at the cost of providing names for all 
> prototype 
> parameters and keeping the syscall name and the name of the 
> respective 
> kernel function consistent (_kern_XYZ() and _user_XYZ()).

That's not really that high a cost ;-)

> Some oddities remain (cf. syscalls.c), for instance that the syscall 
> _kern_exit() was (and still is) mapped to _user_exit_thread(), or 
> that the 
> parameters of _kern_spawn_thread() and _user_spawn_thread() as well 
> as 
> those of _kern_wait_for_team() and _user_wait_for_team() are not 
> consistent. To those in the know, please have a look at this.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alan Grimes | 29 Aug 2004 03:33
Favicon

The Glorrious OS-Troll arives. =P

I noticed the plea for help on the BeOS kernel and decided I had to 
join the list. 

The subject line is refferance to the fact that I've been trolling 
about OSes for as long as I can remember. I've designed my own but have 
been unable to implement it on my own due to the complexities of the PC 
architecture, the absense of decient documentation of all hardware 
outside of the CPU and the complete unwillingness of the GCC and 
Binutils teams to document how to design a loader, VM, and linker-
scripts to support programs compiled with their toolchain. 

*sigh*...

Maybe I'll learn what I need from this project. 

In return I can help clean up your design and make it really pretty. =) 

If you want to know what I've designed, take a look at 

users.rcn.com/alangrimes/UCE/sphere.txt 

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 1 comment |
headers
Ingo Weinhold | 29 Aug 2004 14:01
Picon

Re: VFS syscall and syscall mechanism changes


On 2004-08-29 at 04:40:15 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@...> wrote:
> 
> I've got some small questions regarding your changes, though:
> 
> 1) you changed (most probably) all occurences of something like:
>     strlcpy(pathBuffer, path, SYS_MAX_PATH_LEN - 1);
> to:
>     strlcpy(pathBuffer, path, SYS_MAX_PATH_LEN);
> While I am not entirely sure ATM, I think I did that because the path
> function could add "/." to the final path, and thus 2 characters more
> were required. But maybe I just remember wrong, and it was just ".".

There are two functions that append something to the path: check_path() and 
get_dir_path_and_leaf() (refactored out of path_to_dir_vnode()). Both 
append at most a single '.'. Even, if both were invoked in sequence, only 
the first one would append something.

> 2) I know the change made to _user_read_stat() and the old
> _user_read_path_stat() just makes the previous inconsistency more
> obvious, I don't like the mix of fd and direct function call - if
> someone has a better idea, please shout.

Now that you mention it, I think, I made it indeed worse than before. 
_kern_read_stat() returned the stat associated with the type of the file 
descriptor while _kern_read_path_stat() returned the stat for the node 
referred to by the given path. That is _kern_read_path_stat() was basically 
a _kern_read_stat(_kern_open(...)). Maybe we should go back to that 
semantics (and rename the syscall to _kern_read_node_stat()) and
(Continue reading)

Permalink | Reply | 5 comments |
headers
Axel Dörfler | 29 Aug 2004 16:47
Picon

Re: VFS syscall and syscall mechanism changes

Ingo Weinhold <bonefish@...> wrote:
> On 2004-08-29 at 04:40:15 [+0200], Axel Dörfler wrote:
> > Ingo Weinhold <bonefish@...> wrote:
> > 
> > I've got some small questions regarding your changes, though:
> > 
> > 1) you changed (most probably) all occurences of something like:
> >     strlcpy(pathBuffer, path, SYS_MAX_PATH_LEN - 1);
> > to:
> >     strlcpy(pathBuffer, path, SYS_MAX_PATH_LEN);
> > While I am not entirely sure ATM, I think I did that because the 
> > path
> > function could add "/." to the final path, and thus 2 characters 
> > more
> > were required. But maybe I just remember wrong, and it was just 
> > ".".
> There are two functions that append something to the path: 
> check_path() and 
> get_dir_path_and_leaf() (refactored out of path_to_dir_vnode()). Both 
> append at most a single '.'. Even, if both were invoked in sequence, 
> only 
> the first one would append something.

Okay, then this was a safe change, thanks :)

> > 2) I know the change made to _user_read_stat() and the old
> > _user_read_path_stat() just makes the previous inconsistency more
> > obvious, I don't like the mix of fd and direct function call - if
> > someone has a better idea, please shout.
> Now that you mention it, I think, I made it indeed worse than before.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Waldemar Kornewald | 29 Aug 2004 17:00
Picon

Re: VFS syscall and syscall mechanism changes

> Yes, but I just like the commenting style better than this /*! !*/ - 
> that looks like an alien to me; I've obviously got a hard time getting 
> used to it :)

Maybe this one looks better to you: /*! */ It is half-alien. :))
IMHO, a having a standard is better than our current situation.

Bye,
Waldemar

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click
Permalink | Reply | 1 comment |
headers
Ingo Weinhold | 29 Aug 2004 18:25
Picon

Re: VFS syscall and syscall mechanism changes


On 2004-08-29 at 16:47:54 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@...> wrote:
> > On 2004-08-29 at 04:40:15 [+0200], Axel Dörfler wrote:
>
> > > 2) I know the change made to _user_read_stat() and the old
> > > _user_read_path_stat() just makes the previous inconsistency more
> > > obvious, I don't like the mix of fd and direct function call - if
> > > someone has a better idea, please shout.
> > Now that you mention it, I think, I made it indeed worse than before.
> > _kern_read_stat() returned the stat associated with the type of the
> > file
> > descriptor while _kern_read_path_stat() returned the stat for the
> > node
> > referred to by the given path. That is _kern_read_path_stat() was
> > basically
> > a _kern_read_stat(_kern_open(...)). Maybe we should go back to that
> > semantics (and rename the syscall to _kern_read_node_stat()) and
> > re-introduce the original _kern_read_stat().
> 
> And _kern_read_node_stat() would get the (fd, path) pair, then? Or only
> the path? Because then, I wouldn't see a reason to remove the "path"
> part of the name :)

Of course still both fd and path -- the whole point of the change was to 
allow for such pairs. :-)

> Anyway, it might be a good idea to do so.

OK, I'll change that (earlier or later :-).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander G. M. Smith | 30 Aug 2004 02:56
Favicon

Re: The Glorrious OS-Troll arives. =P

Alan Grimes wrote on Sun, 29 Aug 2004 01:33:25 GMT:
> Maybe I'll learn what I need from this project. 
> 
> In return I can help clean up your design and make it really pretty. =) 

I guess the easy way to get started is to proof read other people's code.  Could help you learn how to set up the
x86 virtual memory system and all those little details you need to know to write an OS on existing hardware.

- Alex

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 0 comments |

Gmane