syllable-kernel — The list is for discussion of Kernel issues by developers

Re: [Syllable-kernel] C99 kernel source preview - needs more work

[Daniel G. <da...@fp...>]

Take two, now that the list works again.

On Tue, 2005-02-15 at 23:38 -0800, Jake Hamby wrote:
>I'm about 90% completed with my C99 typesafe conversion of the kernel 
>sources, and the code now compiles with few warnings (and the
remaining 
>ones I know how to fix), and IMHO is a lot easier to read.  The only 
>problem is that it doesn't work yet!  I'm getting a bunch of error 
>messages that scroll off the screen too quickly for me to read.  I'll 
>try to capture the error messages tomorrow using VMware and continue 
>debugging, but in the meantime I wanted to post what I have so far and 
>hopefully get some feedback and suggestions from the kernel hackers on 
>the list.  Here's the new source (I didn't try to create diffs: the 
>changes are too extensive).

Sounds good, I'll take a look if I get a chance.  I'm going on vacation
next week, tho, so don't hold your breath...


>
>http://anobject.com/jhamby/c99_kernel.tar.bz2
>
>Main highlights:
>
>* Compiles in C99 mode with few warnings and almost all warning
options 
>enabled.
>* uint8, uint16, uint32 are gone, replaced with uint8_t, uint16_t,
etc., 
>or one of these symbolic types:
>
>status_t  - most functions return this.. it's a uint_fast32_t
>count_t   - useful for loop counters and count variables
>flags_t   - used for variables holding flags or mode bits
>handle_t  - used to return a handle, when there wasn't already a type 
>for it, e.g. sem_id, area_id, etc.

All fine, in my opinion.

>
>* I've tried to follow a consistent pattern; most functions will have 
>one or more of these:
>
>status_t foo( struct Foo_s *psFoo )
>{
>       status_t nError = 0;
>
>       flags_t nFlg = cli();
>       sched_lock();
>
>       for ( count_t i = 0; i < psFoo->ff_nCount; ++i )
>       {
>               // do something
>               nError = ( -ENOMEM );
>       }
>
>       sched_unlock();
>       put_cpu_flags( nFlg );
>
>       return nError;
>}

I've locally modified the spin_lock() setup to automatically
save/restore interrupt masks, because it's almost always done that way,
but that can wait.
>

>/**
>  * Description of function.
>  * \param nFoo param 1
>  * \return the answer to life, the universe, and everything (42).
>  * \pre precondition
>  * \post postcondition
>  * \invariant pre- and post- and in-between condition :-)
>  */

I've added to this, and it might be generally useful:
 * \par Locks Required:
 * \par Locks Taken:

Then again, it might not, but the scheduler locks all over the place, so
I think it's usefull there.

>
>I also have a question for Daniel:  I would like to use the DLIST_ 
>macros in more places but unfortunately your version doesn't have a 
>pointer to the tail of the list so there's no quick way to append an 
>item to the end of a list or get the last item, operations which are 
>needed by most of the kernel's lists.  Do you have any plans for a new 
>version of dlist.h that might address this?  If you can add that 
>functionality to DLIST, then I'll take care of patching up the rest of 
>the kernel to use it.

It could definitely be done.  I have a version that does that locally.
However, there are two ways to do it, and I want an opinion on which to
use.  The first way is to just make the DLIST macros be a tail-queue.
The second is to introduce a second set of DLIST macros that are a
tail-queue, and keep the old ones unchanged.  The problem with a tail
queue is that you need the head pointer more often (in particular,
append and remove both need the head pointer in the tail-queue version,
but not in the current version).  Opinions?

Daniel

Re: [Syllable-kernel] ping..

[Daniel G. <da...@fp...>]

On Wed, 2005-02-16 at 16:01 -0800, Jake Hamby wrote:
>Testing to see if the list server is still down?
>
>-Jake

pong?

Daniel

[Syllable-kernel] ping..

[Jake H. <jh...@po...>]

Testing to see if the list server is still down?

-Jake

[Syllable-kernel] C99 kernel source preview - needs more work

[Jake H. <jh...@po...>]

I'm about 90% completed with my C99 typesafe conversion of the kernel 
sources, and the code now compiles with few warnings (and the remaining 
ones I know how to fix), and IMHO is a lot easier to read.  The only 
problem is that it doesn't work yet!  I'm getting a bunch of error 
messages that scroll off the screen too quickly for me to read.  I'll 
try to capture the error messages tomorrow using VMware and continue 
debugging, but in the meantime I wanted to post what I have so far and 
hopefully get some feedback and suggestions from the kernel hackers on 
the list.  Here's the new source (I didn't try to create diffs: the 
changes are too extensive).

http://anobject.com/jhamby/c99_kernel.tar.bz2

Main highlights:

* Compiles in C99 mode with few warnings and almost all warning options 
enabled.
* uint8, uint16, uint32 are gone, replaced with uint8_t, uint16_t, etc., 
or one of these symbolic types:

status_t  - most functions return this.. it's a uint_fast32_t
count_t   - useful for loop counters and count variables
flags_t   - used for variables holding flags or mode bits
handle_t  - used to return a handle, when there wasn't already a type 
for it, e.g. sem_id, area_id, etc.

* I've tried to follow a consistent pattern; most functions will have 
one or more of these:

status_t foo( struct Foo_s *psFoo )
{
	status_t nError = 0;

	flags_t nFlg = cli();
	sched_lock();

	for ( count_t i = 0; i < psFoo->ff_nCount; ++i )
	{
		// do something
		nError = ( -ENOMEM );
	}

	sched_unlock();
	put_cpu_flags( nFlg );

	return nError;
}

* One idea I had which helped a lot with function prototyping was to 
define a macro __SYSCALL(), which expands to the function_name() and 
also, if __KERNEL__ is defined, to sys_function_name().  See, e.g. 
<posix/unistd.h> which has a bunch of these:

__SYSCALL( int,	  rmdir(const char *_path) );

This gives a prototype for rmdir() and also sys_rmdir() in the kernel. 
In the few cases where the system call prototype is different from the 
user-mode version, for example the get_system_info() wrapper passes a 
hidden version number to sys_get_system_info(), then you can't use 
__SYSCALL(), and it's obvious that there's something unusual going on.

* There were a few cases where const was used in prototypes 
unnecessarily, e.g.:

	foo( const int nFoo, const thread_id nThread );

Since the parameter is an integer passed by value, it's impossible for 
the kernel to modify the user's copy.  Whether or not the kernel 
modifies its local copy of nFoo is irrelevant to the user, and so it 
shouldn't be in the method signature.

Finally, I removed my ugly "box" style of doxygen comments and replaced 
them with the more traditional and easier to read:

/**
  * Description of function.
  * \param nFoo param 1
  * \return the answer to life, the universe, and everything (42).
  * \pre precondition
  * \post postcondition
  * \invariant pre- and post- and in-between condition :-)
  */

I also have a question for Daniel:  I would like to use the DLIST_ 
macros in more places but unfortunately your version doesn't have a 
pointer to the tail of the list so there's no quick way to append an 
item to the end of a list or get the last item, operations which are 
needed by most of the kernel's lists.  Do you have any plans for a new 
version of dlist.h that might address this?  If you can add that 
functionality to DLIST, then I'll take care of patching up the rest of 
the kernel to use it.

-Jake

RE: [Syllable-kernel] Arno's kernel patches

[Kristian V. <Kri...@an...>]

Jake Hamby wrote:
> Speaking of bad performance, I'm frustrated that there are a 
> couple of threads that chew up a big chunk of CPU time on my system:
> 
> dbterm:  main thread (14%), read thread (7%)
> media_server_flush:  21.7%
> ata_cmd_thread:  up to 17% for each thread
> appserver: keyb_thread: 7.1%
> appserver: input_thread:  2.6%

dbterm is almost certainly because it has to poll the kernel for new
data on the kernel debug port.
ata_cmd_thread may currently have some tight loops in it where it is
impossible to do anything else but poll for a status change.  The ATA
controller only raises an interupt at certain times.  If you're just
waiting for E.g. STATUS_BUSY to go low you must poll the status register
until it happens.  The best you can do is snooze() during the loop.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

RE: [Syllable-kernel] Arno's kernel patches

[Kristian V. <Kri...@an...>]

Arno Klenke wrote:
> The kernel patch is now available. It changes the following things:
> 
> *Fixes the acpi table parsing errors and adds a kernel option 
> to disable 
> the acpi support
> *Removes the unnecessary cli()/put_cpu_flags() calls
> *Removes the reflect_irq_to_realmode() call

I'm curious about this change:

-	g_sSysBase.ex_GDT[0x40 << 3].desc_lmh &= 0x8f;
+	g_sSysBase.ex_GDT[0x40 >> 3].desc_lmh &= 0x8f;

I seem to recall yourself or Jake mentioning an issue with the GDT
descriptor, I assume this is the fix?  What effect does this have
E.g. does it fix stability on SMP systems?

I'm guessing that code hasn't changed since AtheOS..how did it ever
work correctly in the first place?

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: [Syllable-kernel] Arno's kernel patches

[Jake H. <jh...@po...>]

Arno Klenke wrote:
> The kernel patch is now available. It changes the following things:
> 
> *Fixes the acpi table parsing errors and adds a kernel option to disable 
> the acpi support
> *Removes the unnecessary cli()/put_cpu_flags() calls
> *Removes the reflect_irq_to_realmode() call

Sounds good.  I'll check them in soon.

> P.S.: Your code to increase the timer precision has caused a really 
> _huge_ performance drop on my system

Interesting.  There must be something in the kernel or in user space 
that is calling get_system_time() or get_real_time() frequently enough 
for the overhead of disabling interrupts and reading the PIT timer value 
to be noticable.  I'll look into it.

Speaking of bad performance, I'm frustrated that there are a couple of 
threads that chew up a big chunk of CPU time on my system:

dbterm:  main thread (14%), read thread (7%)
media_server_flush:  21.7%
ata_cmd_thread:  up to 17% for each thread
appserver: keyb_thread: 7.1%
appserver: input_thread:  2.6%

I haven't yet been able to look into why these threads are using so much 
CPU time, but, except for the ata_cmd_threads, the problems seem to be 
due to polling and snoozing for events rather than blocking until an 
event arrives.

-Jake

Re: [Syllable-kernel] Arno's kernel patches

[Arno K. <arn...@ya...>]

The kernel patch is now available. It changes the following things:

*Fixes the acpi table parsing errors and adds a kernel option to disable 
the acpi support
*Removes the unnecessary cli()/put_cpu_flags() calls
*Removes the reflect_irq_to_realmode() call

The patch is available here:

http://www.liqwyd.com/arno/kernel_patch.zip

P.S.: Your code to increase the timer precision has caused a really 
_huge_ performance drop on my system

Arno

Re: [Syllable-kernel] Arno's kernel patches

[Jake H. <jh...@po...>]

Arno Klenke wrote:
> 
> My syllable installation has crashed so I currently cannot access the 
> patched kernel code that is on another afs partition. Please give me 
> some days to reinstall my system. To the cli()/put_cpu_flags() removal: 

I'm sorry to hear that.  One safety measure that I've taken is to 
perform regular backups of my Syllable partition to DVD-RW using Nero 
BackItUp from Windows, part of Nero 6 ultra edition.

> The current instability of the kernel cannot be caused by these removals 
> because Vanders also reports the same crashes when using the cvs kernel 
> code which still contains these calls.

That makes sense.  I suspect that our problems break down into a couple 
of categories:

1) 32-bit signed/unsigned comparison issues.  The current code is a bit 
cavalier about doing pointer arithmetic using uint32's and int32's.  As 
we push our 32-bit systems to the limits of memory capacity (4GB or even 
higher with PAE 36-bit addressing), it's important to be careful here, 
especially since we know we have bugs on large memory systems.  I'm 
about 90% complete with a fairly major search-and-replace job to convert 
the kernel to use the standard and more descriptive C99 types, such as 
uintptr_t and size_t instead of uint32, or the Syllable-specific types 
like status_t for return values instead of int.  This will prepare us 
for 64-bit support, but will screw up everyone's diffs from the current 
kernel.  Hopefully, by the time your Syllable installation is set up 
again, you can start hacking from the new, stronger-typed sources. 
Daniel is probably the only other person who will be impacted by this, 
but I'll post the diffs here at least a week in advance of committing 
them to CVS so we can merge our patches.

2) GCC sometimes inlines, sometimes doesn't inline, functions marked 
"inline".  I thought it would be better to write more functions as 
static inline, rather than as #define macros, but it now seems that some 
of these functions only work correctly when inlined, e.g. the inline 
definition of Fork() in init.c.  And now it appears there are others 
that only work correctly when not inlined.  Perhaps changing the 
performance by inlining, even though either version should be correct, 
is exposing race conditions or other timing issues on SMP systems.

3) Pre- and post-conditions.  We should have some standard convention to 
document pre- and post-conditions for calling a function (such as that 
interrupts must already be disabled), presumably in the doxygen, as well 
as using asserts more aggressively to verify these conditions, as well 
as any loop invariants.  This will help us to catch any incorrect 
assumptions in function usage.

-Jake

Re: [Syllable-kernel] Arno's kernel patches

[Arno K. <arn...@ya...>]

Jake Hamby schrieb:

> Did Arno Klenke release his kernel patches to anyone in source form?  
> I have his latest kernel.so and the patches from Dec. 30, but nothing 
> else.  I sent him a private e-mail so I'm sure I'll hear back from him 
> soon.


My syllable installation has crashed so I currently cannot access the 
patched kernel code that is on another afs partition. Please give me 
some days to reinstall my system. To the cli()/put_cpu_flags() removal: 
The functions where I removed this calls are all called from assembler 
code within syscall.s which already disables the interrupts. So it 
shouldn´t matter if these calls are present or not. However, I already 
had a similiar problem when we switched to gcc3. The kernel just locked 
up while booting. The solution was to move up the put_cpu_flags() call 
in the TimerInterrupt() function. I did not investigate this problem 
further but it seem
ed that put_cpu_flags() just doesn´t have to be the last call in a 
function. If I put some useless code after the call then it worked, 
otherwise not.

The current instability of the kernel cannot be caused by these removals 
because Vanders also reports the same crashes when using the cvs kernel 
code which still contains these calls.

Arno

RE: [Syllable-kernel] Future directions..

[Daniel G. <da...@fp...>]

On Wed, 2005-02-09 at 09:17 +0000, Kristian Vandervliet wrote:
>Daniel Gryniewicz wrote:
>> On Tue, 2005-02-08 at 11:23 -0800, Jake Hamby wrote:
>>>Here's a quick .plan file from me with my work on the 
>>> Syllable kernel.  I'm focused right now on POSIX, UNIX03,
>>> and other stds. compliance for the maximum compatibility
>>> with Linux/GNU and other open-source applications,
>>> especially in preparation for freezing binary 
>>> compatibility for Syllable 0.6.0.  These would include:
>>>
>>> * Vanders' GNU libc port, which is rapidly nearing
>>> completion, but is missing a few critical pieces on the
>>> kernel side, e.g. truncate().
>> 
>> I wrote truncate() support at one point for the VFS and for 
>> AFS.  I can dig out the patches and send them along.  I don't
>> think either has changed since.
>
>Your patches should be current.  My creaky memory couldn't remember
>if the truncate support was complete.  It seems it is, which is great.
>

Well, it was complete, for AFS, but not for anything else.  Also, now
that there's a new glibc, I'll have to make new glibc patches to go with
it.  Working on it now.

Daniel

RE: [Syllable-kernel] Good artists borrow, great artists steal!

[Kristian V. <Kri...@an...>]

Jake Hamby wrote:
> One question:  is there any reason, licensing or otherwise, 
> for us not to also steal high-quality code from FreeBSD?

None at all, provided a) The semantics of the code fit with the
rest of the system without much work b) The code in question is
under the newer, non-advertsing, GPL compatable BSDL.

> Here are the particular pieces of BSD that I'm interested in:
> 
> * kernel malloc():  we need a better implementation than the 
> Linux 2.0.x malloc() we're using now.

Agreed.  The current allocator is slow and I believe, pretty
inefficient.

> * FreeBSD NFS implementation (unless NetBSD or OpenBSD is better?)

Some people would like to have NFS support, no doubt.  How smoothly
could we integrate NFS into Syllable?  An "NFS client" would be best
as a filesystem driver.  There is something in CVS at
syllable/misc/drivers/fs/nfs/ which claims to be an "NFS like" driver,
and a quick glance over the code looks as though runs with both a 
client and server thread.  I don't know anything at all about NFS
so I don't know how "NFS" like this is, or even if it's a good way
to it.

> * any relevant code from FreeBSD's TCP/IP stack, keeping intact our 
> Syllable-native TCP/IP implementation while adding any new 
> features or performance enhancing algorithms.

Sounds good to me.  Better support for various socket flags,
getsockopt() and setsockopt() would be good start.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

RE: [Syllable-kernel] Future directions..

[Kristian V. <Kri...@an...>]

Daniel Gryniewicz wrote:
> On Tue, 2005-02-08 at 11:23 -0800, Jake Hamby wrote:
>>Here's a quick .plan file from me with my work on the 
>> Syllable kernel.  I'm focused right now on POSIX, UNIX03,
>> and other stds. compliance for the maximum compatibility
>> with Linux/GNU and other open-source applications,
>> especially in preparation for freezing binary 
>> compatibility for Syllable 0.6.0.  These would include:
>>
>> * Vanders' GNU libc port, which is rapidly nearing
>> completion, but is missing a few critical pieces on the
>> kernel side, e.g. truncate().
> 
> I wrote truncate() support at one point for the VFS and for 
> AFS.  I can dig out the patches and send them along.  I don't
> think either has changed since.

Your patches should be current.  My creaky memory couldn't remember
if the truncate support was complete.  It seems it is, which is great.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Syllable-kernel] Latest CVS kernel

[Kristian V. D. V. <va...@li...>]

Jake,

I compiled kernel 0006 with Gcc 3.4.3 and found a few issues:

o On a single CPU P2 400 the ACPI code detects 16 CPU's and causes a hang on
   boot.  This is the same problem I had with Arno's original kernel.  It
   looks like the later changes Arno made to fix this are missing from the
   kernel.  I have to boot with disable_smp=true
o Even with SMP disabled the system locked up during compilation of Samba
   3.0.10.  This happened twice, but with no stack trace generated.  Gcc had
   died (Or was using no CPU) but I could not ^C my way back to Bash in either
   of the terminal sessions I had running.  This could be the same problems
   myself and others have seen with Arnos last series of changes.
o My strace errno-printing patch doesn't appear to be in CVS.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

Re: [Syllable-kernel] Good artists borrow, great artists steal!

[Mark W. <ma...@cl...>]

> One question:  is there any reason, licensing or otherwise, for us not
> to also steal high-quality code from FreeBSD?

Bear in mind there are actually two BSD licenses...

> The BSD's already use 
> GNU-licensed code 

Yes but only in userspace.

> and I believe the Linux kernel has used BSD-licensed 
> code as well. 

Yes, that's true, although I haven't seen large amounts of BSD code around the 
kernel.

> I'm not aware of any legal issues involved in intermixing 
> the two

The original license had 4 clauses.  It is "free" but it is not compatible 
with GPLv2 because there is an advertising clause.  See 
http://www.fsf.org/licenses/info/BSD_4Clause.html

After some time, Berkeley changed all the code they had copyright to the 3 
clause license, dropping the advertising clause.  See 
http://www.fsf.org/licenses/info/BSD_3Clause.html

There is still other 4 clause licensed code in various parts of the BSD 
kernel, however.  Off the top of my head, the USB stack code is 4 clause 
licensed, there are probably other bits.

> Anything else?

It seems like a good idea to pick and choose whatever is relevant from other 
projects.  That's a big OSS win, after all ;-)

Cheers,
Mark

[Syllable-kernel] Good artists borrow, great artists steal!

[Jake H. <jh...@po...>]

It was Picasso who coined the phrase in the subject of this message. 
One reason I enjoy developing for Syllable is that we're free to take 
high-quality tested implementations of things like glibc and GCC from 
GNU/Linux, thus saving developer effort that can go towards improving 
the Syllable-native code instead.

One question:  is there any reason, licensing or otherwise, for us not 
to also steal high-quality code from FreeBSD?  The BSD's already use 
GNU-licensed code and I believe the Linux kernel has used BSD-licensed 
code as well.  I'm not aware of any legal issues involved in intermixing 
the two, along with the GNU-licensed code written by Kurt, Arno, Daniel, 
Vanders, myself, and others, but I want to make sure no one else has any 
objections.

Here are the particular pieces of BSD that I'm interested in:

* kernel malloc():  we need a better implementation than the Linux 2.0.x 
malloc() we're using now.  Unfortunately, the Linux 2.2.x - 2.6.x 
"slabs" allocator uses a lot of global variables and is scattered across 
several files.  If the FreeBSD allocator is superior, then I would 
prefer to import that instead.

* FreeBSD NFS implementation (unless NetBSD or OpenBSD is better?). 
Linux's NFS has never been very good.  FreeBSD is beginning to support 
NFSv4, while Solaris 10 is freely available for interoperability 
testing.  Of course, for desktop users, Samba will be more important, 
however for interop w/ UNIX systems, or even Darwin/OSX, NFS support 
could not hurt.

* any relevant code from FreeBSD's TCP/IP stack, keeping intact our 
Syllable-native TCP/IP implementation while adding any new features or 
performance enhancing algorithms.

Anything else?

-Jake

Re: [Syllable-kernel] Future directions..

[Jake H. <jh...@po...>]

Daniel Gryniewicz wrote:
> 
> I wrote truncate() support at one point for the VFS and for AFS.  I can
> dig out the patches and send them along.  I don't think either has
> changed since.

Yeah, Vanders mentioned that you had written some patches.  Please send 
them along if you can find them.

Finishing up my list of notes:

* One big concern I have is that the amount of CPU time that is being 
consumed by daemon threads is far too much.  The biggest culprits are 
media_server_flush, ata kernel threads, and dbterm.  cpumon reports as 
much as 10% CPU usage on a 3.0GHz P4 system just idling!  It should be 
less than 1%.

* The kernel now (as of Build 0006 in CVS) has a microsecond-accurate 
get_real_time() capability which translates into usec-accurate 
gettimeofday() from either version of glibc.  Great for benchmarking. 
It uses no additional resources and works by adding the fraction of the 
PIT timer that has elapsed since the last interrupt to the current time 
counter.  Now, esp. after we take care of the time-wasting daemon 
threads), we'll be able to take lmbench results before and after 
experimenting with different optimizations.

* The kernel now builds w/o errors on GCC 3.4.3.  Rather than switching 
immediately to C++ for the kernel, which would be more confusing than 
helpful to us, I propose that we start building the kernel with 
"-std=gnu99", which is C99 + GNU extensions, and is the flag used for 
building glibc.  The most convenient new C99 feature is probably being 
able to declare new variables anywhere in a function, so you can write 
the C++ style:

for (int i=0; i<99; ++i)  { }

instead of having to declare "i" at the top of the function.

-Jake

Re: [Syllable-kernel] Future directions..

[Daniel G. <da...@fp...>]

On Tue, 2005-02-08 at 11:23 -0800, Jake Hamby wrote:
>Here's a quick .plan file from me with my work on the Syllable kernel. 
>I'm focused right now on POSIX, UNIX03, and other stds. compliance for 
>the maximum compatibility with Linux/GNU and other open-source 
>applications, especially in preparation for freezing binary 
>compatibility for Syllable 0.6.0.  These would include:
>
>* Vanders' GNU libc port, which is rapidly nearing completion, but is
>missing a few critical pieces on the kernel side, e.g. truncate().

I wrote truncate() support at one point for the VFS and for AFS.  I can
dig out the patches and send them along.  I don't think either has
changed since.

Daniel

[Syllable-kernel] Future directions..

[Jake H. <jh...@po...>]

Here's a quick .plan file from me with my work on the Syllable kernel. 
I'm focused right now on POSIX, UNIX03, and other stds. compliance for 
the maximum compatibility with Linux/GNU and other open-source 
applications, especially in preparation for freezing binary 
compatibility for Syllable 0.6.0.  These would include:

* Vanders' GNU libc port, which is rapidly nearing completion, but is
missing a few critical pieces on the kernel side, e.g. truncate().

* the latest gcc 3.4.x branch, whether Fedora or Gentoo's regular ebuild
updates; the latest ebuild ChangeLog in Gentoo says that gcc-3.4.3
has bugs in the SSE (PIII/PIV/AthlonXP) code generation so we should 
probably use a later code drop (Gentoo is using gcc-3.4.3.20050110).

* I'm working on completing the Syllable-specific pty handling code for 
glibc 2.3.3 -- soon we will have openpty(), grantpt(), unlockpt(), 
ttyname(), ttyname_r(), ptsname(),  and ptsname_r().  Those functions 
aren't used by most UNIX apps, but are critical for programs like xterm 
and ssh sessions (in fact all "terminals" except for the actual hardware 
serial port ttys that they are a simulation of) to work, as well as a 
requirement for porting the GNU testing utility dejagnu, which depends 
on a TCL extension called Expect.  aterm and ssh are rock-solid for me 
so it's pretty obvious that our pty/tty code is working (mostly) 
correctly, but aterm is using a non-portable, old-style BSD way of 
creating ptys that should be upgraded to use the new pty API's. 
Interestingly, the pty code in vfs/pty.c will allow you to create a pty 
of *any* filename in /dev/pty/mst/ along with the matching file in 
/dev/pty/slv/.  Right now aterm creates /dev/pty/mst/pty[0-10000].  I 
propose to use Linux/POSIX style /dev/pty/mst/[0-10000] and 
/dev/pty/slv/[0-10000], i.o.w. the filename would be just the
number.  On the master side, it may be better to switch to a single 
file, e.g. Linux and Solaris use /dev/ptmx for all masters and the slave 
side is /dev/pts/[0-10000].  I'll patch aterm to use the new GNU libc 
functions instead of opening the ptys by hand.  There is about 100 lines 
of configuration stuff that the calls in -lutil, openpty() and forkpty() 
perform that aterm, openssh, etc. should be taking advantage of.

* Timezones.  We are very close to having zic running and installing
compiled versions of all the timezone info in /usr/glibc/... This will
enable us to upgrade DateTime to have actual functioning timezone
support and programs like "date" to show the correct tz abbreviation.
This being a PC system where users are equally likely to dual-boot into
Windows as they are into Linux, DateTime should allow you to set whether
your battery-backed clock is set to GMT or to your local timezone.

Part II coming up...

-Jake

Re: [Syllable-kernel] Sorry, testing

[Daniel G. <da...@fp...>]

On Thu, 2005-02-03 at 20:34 +0000, Kristian Van Der Vliet wrote:
> On Thursday 03 February 2005 20:22, Daniel Gryniewicz wrote:
> > On Thu, 2005-02-03 at 20:15 +0000, Kristian Van Der Vliet wrote:
> >> Just a test.
> >
> > Awww.  And you had me hoping this was some great announcement, like
> > working wireless or a native openoffice port. ;)
> 
> Sorry!  Some people had noted the list was playing up and it was pretty dead 
> on here, I wondered if it was an issue or not.  Apparently it's all working, 
> you're all just very quiet!
> 

No, I've just hit a snag in my scheduler cleanups, in the form of
eventual hang under load, and Abrowse not working at all.  I haven't
gotten any further than that yet.  I suppose I could post more gcc 3.4
cleanups.

Daniel

Re: [Syllable-kernel] Sorry, testing

[Kristian V. D. V. <va...@li...>]

On Thursday 03 February 2005 20:22, Daniel Gryniewicz wrote:
> On Thu, 2005-02-03 at 20:15 +0000, Kristian Van Der Vliet wrote:
>> Just a test.
>
> Awww.  And you had me hoping this was some great announcement, like
> working wireless or a native openoffice port. ;)

Sorry!  Some people had noted the list was playing up and it was pretty dead 
on here, I wondered if it was an issue or not.  Apparently it's all working, 
you're all just very quiet!

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

Re: [Syllable-kernel] Sorry, testing

[Daniel G. <da...@fp...>]

On Thu, 2005-02-03 at 20:15 +0000, Kristian Van Der Vliet wrote:
> Just a test.

Awww.  And you had me hoping this was some great announcement, like
working wireless or a native openoffice port. ;)

Daniel

[Syllable-kernel] Sorry, testing

[Kristian V. D. V. <va...@li...>]

Just a test.
-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

Re: [Syllable-kernel] List admin change

[Daniel G. <da...@fp...>]

On Tue, 2005-02-01 at 07:56 +0000, Kristian Van Der Vliet wrote:
> Just a quick note to let you all know that I've raised the attachment size 
> limit on both Syllable-Developer and Syllable-Kernel from 40kb to 100kb.  I 
> was O.K'ing pretty much everything anyway, so for most of you this makes no 
> difference.  For those of you sending attachments, it makes life easier 
> because you don't have to wait for me to clear them!
> 

Thank you!

Daniel (who keeps forgetting about the 40Kb limit...)

[Syllable-kernel] List admin change

[Kristian V. D. V. <va...@li...>]

Just a quick note to let you all know that I've raised the attachment size 
limit on both Syllable-Developer and Syllable-Kernel from 40kb to 100kb.  I 
was O.K'ing pretty much everything anyway, so for most of you this makes no 
difference.  For those of you sending attachments, it makes life easier 
because you don't have to wait for me to clear them!

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com