You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
|
Aug
|
Sep
|
Oct
(39) |
Nov
(14) |
Dec
(8) |
2005 |
Jan
(46) |
Feb
(36) |
Mar
(5) |
Apr
(12) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
(2) |
2006 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(9) |
Nov
(14) |
Dec
(4) |
2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <uda...@lk...> - 2003-07-09 04:36:10
|
Hi .. I have joined a group on Athfs developer group and posted a question there.. Question -- | 1. Whats the main advantage /disadvantage of Atheos Filesystem in | comparision to other filesystems on Linux .. lets say Ext3 ? Answer -- Well, the AtheOS filesystem is actually a virtual filesystem, so along with physical files & directories, there are also pipes/fifos, device files, etc.. I'm really not the authority on this, certainly you're welcome to ask the Syllable <http://syllable.sf.net/> development team. The main thing about this filesystem is that it's specifically designed for Syllable/AtheOS. Syllable could quite easily use EXT3, and at one stage, it was possible to run it on FAT32, but re-inventing the wheel can be interesting, hence why this OS uses its own. The AthFS project is about bringing this filesystem to the Linux kernel, mainly to allow people to install Syllable & manipulate AthFS partitions from within Linux. But out here i m not conviced that its a virtual filesystem . The case should be like you can actually load the Atheos Filesystem on Linux Machine. As in you can have Amoeba , QNX4.x , etc. Correct me if i m wrong on this. Next what is the advantage/ disadvantage of AtheOS Filesystem , lets say the characteristics of the same. Where can i find some code/documentation links , that can give me a better idea about the AtheOs Filesystem. Regards Udayan |
From: Scott C. K. <sc...@cs...> - 2003-01-18 21:16:31
|
On Sat, 18 Jan 2003, Henrik Isaksson wrote: > > > > > I haven't looked into how Vanders' solution works, but I suppose that > > > make_port_public simply moves the port over to a different list. Having > two > > > lists is definitely desirable over having one lists with all ports in > it, > > > since 90% of all ports will most likely not be public ports, and thus > they > > > would only slow down searching for named ports. > > > > > > > Yes thats correct, make_port_public does move the port to a seperate list, > > what I dont understand is why the need for two lists? Maybe if i looked at > > libatheos it would make sense. There doesnt seem to be much sense in > > having named ports if the names arent unique. find_port only searches > > through the public ports, this solutaion just doesnt make sense to me. > > > > What is the reason for not making the names unique system wide and having > > no concept of public/private ports and find_port searching > > everything. This is what BeOS did and it seemed to work quite well. > > Because you have, let's say 1000 private ports, and perhaps 10 public ports. > If you're looking for one of those 10 ports, you still have to go through > all 1010 ports, if you put them all in one list. > What happens as Syllable grows an an OS an as a platform developers want to be on. They are going to use ports because they are an elegant way to do IPC so maybe you have 1000 private ports and 700 public ports, now you still have to solve your orignal problem of finding an effeciant way to search through the lists of ports but you've shot yourself in the foot because you've got these 1000 ports that can't be accesed by other applications because they're not searchable. I'm not saying I have a complete solution yet but i think the way it is now isn't optimal. Scott Knight University of Pittsburgh |
From: Henrik I. <he...@bo...> - 2003-01-18 21:15:29
|
I've never built the kernel, only libatheos and the appserver, but I guess it's somewhat similar. You have to set up ATHEOS_SRC env variable to the directory where Makefile.rules is. --- Kind Regards, Henrik Isaksson ----- Original Message ----- From: "Scott C. Knight" <sc...@cs...> To: <syl...@li...> Sent: Saturday, January 18, 2003 10:01 PM Subject: [Syllable-kernel] building kernel only > Ive grabbed the whole system directory for syllable out of cvs, Im > interested in building the kernel only. Does anyone know how to do this as > just cd'ing into the /syllable/system/sys/kernel directory and doing a > make wont work because the recurse rules are a couple directories up. > > Scott Knight > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will > allow you to extend the highest allowed 128 bit encryption to all your > clients even if they use browsers that are limited to 40 bit encryption. > Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > _______________________________________________ > Syllable-kernel mailing list > Syl...@li... > https://lists.sourceforge.net/lists/listinfo/syllable-kernel > > |
From: Scott C. K. <sc...@cs...> - 2003-01-18 21:01:56
|
Ive grabbed the whole system directory for syllable out of cvs, Im interested in building the kernel only. Does anyone know how to do this as just cd'ing into the /syllable/system/sys/kernel directory and doing a make wont work because the recurse rules are a couple directories up. Scott Knight |
From: Scott C. K. <sc...@cs...> - 2003-01-18 16:28:24
|
> I haven't looked into how Vanders' solution works, but I suppose that > make_port_public simply moves the port over to a different list. Having two > lists is definitely desirable over having one lists with all ports in it, > since 90% of all ports will most likely not be public ports, and thus they > would only slow down searching for named ports. > Yes thats correct, make_port_public does move the port to a seperate list, what I dont understand is why the need for two lists? Maybe if i looked at libatheos it would make sense. There doesnt seem to be much sense in having named ports if the names arent unique. find_port only searches through the public ports, this solutaion just doesnt make sense to me. What is the reason for not making the names unique system wide and having no concept of public/private ports and find_port searching everything. This is what BeOS did and it seemed to work quite well. Scott Knight University of Pittsburgh |
From: Henrik I. <he...@bo...> - 2003-01-18 13:22:21
|
> As close as I can tell the purpose of make_port_public is to enforce > uniquness in names, so why not just make the names unique in the first > place. The wiki mentions that it would break compatibility with libatheos. I wrote that... actually, all it would take is to make the changes in libatheos at the same time. (libatheos creates heaps of ports, with names such as "reply port") That particular problem should be easy to address by simply using private ports. I haven't looked into how Vanders' solution works, but I suppose that make_port_public simply moves the port over to a different list. Having two lists is definitely desirable over having one lists with all ports in it, since 90% of all ports will most likely not be public ports, and thus they would only slow down searching for named ports. > Anyone who was around for the start of beos knows that apis changed as it > grew and things had to be re written and it was well worth the time. > > If we are afraid to implement things correctly in the kernel because of > forcing updates in other components the kernel will continue to sit > stagnate. > > I feel to reach the goal that people want of Syllable we are going to have > to take the plunge and start adding to the kernel properly, we shouldnot > be afraid to do things right the first time. I agree... > Im interested in other peoples opinions about this subject? > > And I think i might play around with the messaging code and see if it cant > be cleaned up a bit and how much work that might actually be. > > (oh yeah hopefully someone else is actually subscribed to this list, it > would be nice to see some more posts here) I am, obviously, but I haven't seen anyone else here... --- Kind Regards, Henrik Isaksson |
From: Scott C. K. <sc...@cs...> - 2003-01-18 04:01:46
|
I wanted to try to get some discussion going here in the kernel list and try to see if we couldn't get more people interested in working on the kernel, Im trying to free up some time so possibly I could contribute some. I have some comments about the current messaging implementation in Syllable. Ive read over the wiki topic for public message ports and it doesnt make much sense what the need for make_port_public/private is. I was not around when people discussed this and I havent searched the mailing list for relevant info so maybe someone here can provide me with the information. As close as I can tell the purpose of make_port_public is to enforce uniquness in names, so why not just make the names unique in the first place. The wiki mentions that it would break compatibility with libatheos. Anyone who was around for the start of beos knows that apis changed as it grew and things had to be re written and it was well worth the time. If we are afraid to implement things correctly in the kernel because of forcing updates in other components the kernel will continue to sit stagnate. I feel to reach the goal that people want of Syllable we are going to have to take the plunge and start adding to the kernel properly, we shouldnot be afraid to do things right the first time. Im interested in other peoples opinions about this subject? And I think i might play around with the messaging code and see if it cant be cleaned up a bit and how much work that might actually be. (oh yeah hopefully someone else is actually subscribed to this list, it would be nice to see some more posts here) Scott Knight University of Pittsburgh |
From: Mike T. <mi...@ut...> - 2002-08-28 15:26:12
|
So I figured I would see if it is where we should move kernel talk to Bear Aka Mike Taylor |