Some time after the SCO accusations that the Linux kernel would contain code owned by SCO, the Linux kernel people decided to setup a system for tracking the origin of patches. Unfortunately, this system isn't exactly faultproof. I've only submitted about 10 patches out of which three have been wrongly accredited. And because of GIT's use of hashes as identifiers, these mistakes do not get rectified.
Some time ago two patches of mine ended up in 2.6.11.5 stating someone else being the author. Now, I just noticed another patch of mine ended up somewhere in 2.6.x wrongly accrediting someone else.
maandag, oktober 31, 2005
dinsdag, oktober 18, 2005
vrijdag, oktober 14, 2005
donderdag, oktober 13, 2005
picorb recursive structs
Just finished adding recursive structs to picorb. For in, inout, out parameters and return types. For the moment I have only tested omniORB's interoperability with the new recursive structs code as I need to modify the testing code to do so. Next up will be the Java code, but that's for tomorrow.
What's next on my schedule are: adding support for sequences, user-defined exceptions, variable length types and arrays.
What's next on my schedule are: adding support for sequences, user-defined exceptions, variable length types and arrays.
picorb floppy
I've just created a bootable floppy of which 400K is used, which can be used to demonstrate picorb. GRUB by itself takes 152K on the FAT-formatted disk. eCos and the demo CORBA server implementation take 255K of which eCos takes about 240K. For now, I've taken a basic configuration of eCos, which I intend to strip down. The demo server implements a CORBA object supporting an interface containing 21 methods.
woensdag, oktober 12, 2005
My ORB on PowerPC
My tiny ORB is now also working on my MPC823E embedded board. I've named it "picorb".
dinsdag, oktober 11, 2005
CORBA for eCos
I've just succeeded in getting my new tiny ORB running on eCos within the Qemu emulator! My testsuite of TAO, omniORB and J2SE ORB calls all succeed without a problem. Next up is testing on my PowerPC 823E embedded board to verify the correctness of the endianness related code.
eCos on Qemu
Enabling some tracing output regarding DHCP, BOOTP and in general networking showed that no DHCP requests where being answered by the internal Qemu DHCP server. So, I disabled DHCP for now, and switched to a hardcoded network configuration. This seems to work, the network card gets nicely configured. My ORB runs and binds to the specified interface. But... through the slirp networking code, it doesn't seem to work. Switching to TUN/TAP hasn't given any positive results either.
eCos
I've been playing with eCos lately. As I haven't got enough spare PCs -and because it allows me to work more efficiently- I'm using eCos on Qemu. The network card emulated by Qemu, is the widely support good old NE2000 (both ISA and PCI versions are emulated). Unfortunately, eCos doesn't support that network card, which in one way kinda surprised me, as it was a very widely supported card on desktop OSs. In fact, eCos just supports a few network cards on PC systems. Ofcourse, in another way, this isn't so surprising, x86 and it's related hardware aren't exactly the target of eCos.
Luckily, Antony T Curtis wrote a patch for Qemu to support another network card, the AMD PC-Net II. But, unfortunately, the latest release of eCos doesn't support that card either. Now, I've got three versions of eCos on my system: the latest release from the webpage, the Debian package and the latest CVS tree. After some playing around, I noticed that Qemu kept segfaulting when using the PC-Net card. Some googling turned up a few patches - which BTW have made it into the Xen repository (didn't know Xen was using Qemu) but haven't made it to the Qemu-patches page.
Now, the networkcard is nicely recognised by eCos, but the CVS branch of eCos has some other issues. Ofcourse, this is to be expected, it's the unstable CVS branch where developers push in their latest changes, but still it is kind of annoying. There hasn't been an eCos release in two years or so, so hopefully a new release will follow soon.
For the moment I'm stuck with some annoying issues: When booting Redboot, it just hangs for half a minute. The 2.0 release and also the Debian package with the same configuration on the same system, don't show this behavior. And after this, there's some problem with configuring the network card. I'm not sure whether the networkcard implementation in Qemu is to blame or the eCos driver. And I can't revert to the older eCos release to find out, as it doesn't support the card.
I'm pretty sure my code isn't to blame, as the official test mentioned in the eCos manual (ftp_test.c) doesn't work either. A mail to the eCos mailinglist could help.
Luckily, Antony T Curtis wrote a patch for Qemu to support another network card, the AMD PC-Net II. But, unfortunately, the latest release of eCos doesn't support that card either. Now, I've got three versions of eCos on my system: the latest release from the webpage, the Debian package and the latest CVS tree. After some playing around, I noticed that Qemu kept segfaulting when using the PC-Net card. Some googling turned up a few patches - which BTW have made it into the Xen repository (didn't know Xen was using Qemu) but haven't made it to the Qemu-patches page.
Now, the networkcard is nicely recognised by eCos, but the CVS branch of eCos has some other issues. Ofcourse, this is to be expected, it's the unstable CVS branch where developers push in their latest changes, but still it is kind of annoying. There hasn't been an eCos release in two years or so, so hopefully a new release will follow soon.
For the moment I'm stuck with some annoying issues: When booting Redboot, it just hangs for half a minute. The 2.0 release and also the Debian package with the same configuration on the same system, don't show this behavior. And after this, there's some problem with configuring the network card. I'm not sure whether the networkcard implementation in Qemu is to blame or the eCos driver. And I can't revert to the older eCos release to find out, as it doesn't support the card.
I'm pretty sure my code isn't to blame, as the official test mentioned in the eCos manual (ftp_test.c) doesn't work either. A mail to the eCos mailinglist could help.
maandag, oktober 10, 2005
Tiny CORBA implementation
The 28th of September I started writing a new CORBA implementation. The major goal being minimal footprint while being GIOP compatible. The current footprint of a small Hello World style applications implementing one object containing 21 methods is 16024 bytes as an ELF Linux executable. The textsegment is 13008 bytes for the moment.
Currently, I have the base types working and structs, and I've tested interoperability with omniORB, TAO and Sun's Java ORB of the J2SE SDK. It works on both big-endian and little-endian systems.
I reused the omniORB IDL compiler frontend and implemented a new backend for my ORB, which reliefs me from the pain of writing skeletons manually, which I had to do the first days of the implementation.
I've started porting it to eCos but that isn't quiet working yet.
Currently, I have the base types working and structs, and I've tested interoperability with omniORB, TAO and Sun's Java ORB of the J2SE SDK. It works on both big-endian and little-endian systems.
I reused the omniORB IDL compiler frontend and implemented a new backend for my ORB, which reliefs me from the pain of writing skeletons manually, which I had to do the first days of the implementation.
I've started porting it to eCos but that isn't quiet working yet.
Abonneren op:
Posts (Atom)