Thursday, October 27, 2005
Tip: New compilers, old kernels
I often see customers upgrading their compilers well before upgrading their kernel. This is understandable because frankly, it's a big change to upgrade your whole kernel. But changing your compiler doesn't seem like that big of a deal.
However it is actually a big deal - compilers change, and the kernel needs to change sometimes to accomodate the compiler changes. For example, a problem was reported using GHS Diab 5.0a compiler in conjunction with 4.1 . Now 4.1 is a very old release - I couldn't even find a copy in our offices here. It was originally designed for Windows NT and 98, if that tells you anything. However, some people are still out there using it. The problem reported had to do with C++ constructors not being called. Turns out there are some changes in the way Diab's compiler handles this and basically the 5.0a release is not compatibile with our 4.1 kernel release and some other older releases. In fact, the earliest kernel release that supports 5.0 diab is 4.5.2 . Also customer was trying to mix and match our supplied libraries between kernel versions - not a good idea. For now, they were able to find the old diab and get their C++ constructors working that way.
I have seen a similar thing happen with ghs compiler - ghs 4.07 has some issues with 4.5.2 kernel compile. The environment makefiles supplied by GHS are wrong, but so were ours - ours were closer to right, but still not exactly right. This one requires a couple of makefiles to be replaced down in the kernel (the fixes are available on the ose_support group site). This is another case of a customer upgrading their compiler before upgrading the kernel software.
For our own part, we should probably do a better job of testing the older compilers against newer kernel releases, up to a point. We can't be expected to support a really old compiler or tons of older compiler releases, but we should at least certify a range of compiler releases for each vendor that would work for a given kernel release. We currently certify a specific compiler release to work on a specific kernel release, and we do this for each compiler we support. But it's a one-to-one mapping, and it maybe should be one-to-many instead - the kernel is too big a piece for developers to upgrade without a lot of thought.
However it is actually a big deal - compilers change, and the kernel needs to change sometimes to accomodate the compiler changes. For example, a problem was reported using GHS Diab 5.0a compiler in conjunction with 4.1 . Now 4.1 is a very old release - I couldn't even find a copy in our offices here. It was originally designed for Windows NT and 98, if that tells you anything. However, some people are still out there using it. The problem reported had to do with C++ constructors not being called. Turns out there are some changes in the way Diab's compiler handles this and basically the 5.0a release is not compatibile with our 4.1 kernel release and some other older releases. In fact, the earliest kernel release that supports 5.0 diab is 4.5.2 . Also customer was trying to mix and match our supplied libraries between kernel versions - not a good idea. For now, they were able to find the old diab and get their C++ constructors working that way.
I have seen a similar thing happen with ghs compiler - ghs 4.07 has some issues with 4.5.2 kernel compile. The environment makefiles supplied by GHS are wrong, but so were ours - ours were closer to right, but still not exactly right. This one requires a couple of makefiles to be replaced down in the kernel (the fixes are available on the ose_support group site). This is another case of a customer upgrading their compiler before upgrading the kernel software.
For our own part, we should probably do a better job of testing the older compilers against newer kernel releases, up to a point. We can't be expected to support a really old compiler or tons of older compiler releases, but we should at least certify a range of compiler releases for each vendor that would work for a given kernel release. We currently certify a specific compiler release to work on a specific kernel release, and we do this for each compiler we support. But it's a one-to-one mapping, and it maybe should be one-to-many instead - the kernel is too big a piece for developers to upgrade without a lot of thought.
Wednesday, October 26, 2005
Tasks for the week
So... to get started here are some things on my plate, some of which are customer-driven and others which aren't.
- GHS temp license no longer working. It was supposed to be 180 days, but it stopped working after less than 30. Opened issue for tracking by GHS.
- VPN: now that I've got access I need to get remote compilers working with Clearcase etc.
- Targets: after some LAN reconfiguring, my access to the MBX860 was messed up. Got this fixed the other day. (Note to self : NEVER try to use 192.168.x.x for target!!!) I have two other targets that I'm slowly working on getting going, but other tasks seem to get in the way. One is an OMAP OSK5912 board and the other is an EST8260. I'm hoping to get 5.1 on the OMAP and 4.6 on the 8260.
- iSystem and other misc debugging items: these are languishing here but I do want to get freeze-mode working at some point with either MULTI or GDB. Preferably both.
- received 4.6.1 source in the mail this week. Which is great, except I don't have 4.6.1 release. Which I need to get, I think!
- Other components which I need to get more familiar with like POLO, SNMP etc.
*** Now for some open customer issues. ***
- Illuminator customer using osepmd.jar with fixes. The updated zipped /bin/jre was sent to them this week and I'm waiting to hear if this closes their issue.
- Diab 5.0a compiler issues: working this through with customer still, trying to get them going on the 4.x versions that we know to be working. Customer has install issues now with diab software that they're trying to get worked out.
- GHS linker warning ose_confd.o: no update on this, need to find workaround. My license issue needs to get fixed and/or VPN access to compilers is needed.
- sfk-linux and Illuminator: works for me, but on the site it doesn't see the target app, which is a consultant product. FAE will be onsite soon to work with it more. Need something to monitor the UDP ports for Illuminator to find out why it can't see the app. Tried udplisten but this doesn't work in the context of this sfk, which totally locks up the port (udplisten returns bind() error). We also received some process logs from the customer app, one of which shows very interesting data that looks like a tick() calling process being starved.
- 5.1 BSP for 5912 : changing clock speed appears to have no effect. Paul N. is working very hard on this and explained to customer the impact of fixing it. Customer is okay with this so Paul will send the fixes to them. As far as sourcing, no idea - need to follow up on this so probably I will write a case to get it sourced.
*** Random thoughts ***
Sent some feedback to mgmt about defining End Of Life process. It's good that they're thinking about this, even though it's a painful subject for customers and difficult for the field people sometimes to talk about it with them. I agree though that something is needed - if anything it helps clarify what can be offered for older releases. But if we are not very aggressive about forcing upgrades on the base (i.e. Sun is quite aggressive about this and EOLs their old java stuff as soon as a new release is out), the product retirement process can really drag on for a long time.
- GHS temp license no longer working. It was supposed to be 180 days, but it stopped working after less than 30. Opened issue for tracking by GHS.
- VPN: now that I've got access I need to get remote compilers working with Clearcase etc.
- Targets: after some LAN reconfiguring, my access to the MBX860 was messed up. Got this fixed the other day. (Note to self : NEVER try to use 192.168.x.x for target!!!) I have two other targets that I'm slowly working on getting going, but other tasks seem to get in the way. One is an OMAP OSK5912 board and the other is an EST8260. I'm hoping to get 5.1 on the OMAP and 4.6 on the 8260.
- iSystem and other misc debugging items: these are languishing here but I do want to get freeze-mode working at some point with either MULTI or GDB. Preferably both.
- received 4.6.1 source in the mail this week. Which is great, except I don't have 4.6.1 release. Which I need to get, I think!
- Other components which I need to get more familiar with like POLO, SNMP etc.
*** Now for some open customer issues. ***
- Illuminator customer using osepmd.jar with fixes. The updated zipped /bin/jre was sent to them this week and I'm waiting to hear if this closes their issue.
- Diab 5.0a compiler issues: working this through with customer still, trying to get them going on the 4.x versions that we know to be working. Customer has install issues now with diab software that they're trying to get worked out.
- GHS linker warning ose_confd.o: no update on this, need to find workaround. My license issue needs to get fixed and/or VPN access to compilers is needed.
- sfk-linux and Illuminator: works for me, but on the site it doesn't see the target app, which is a consultant product. FAE will be onsite soon to work with it more. Need something to monitor the UDP ports for Illuminator to find out why it can't see the app. Tried udplisten but this doesn't work in the context of this sfk, which totally locks up the port (udplisten returns bind() error). We also received some process logs from the customer app, one of which shows very interesting data that looks like a tick() calling process being starved.
- 5.1 BSP for 5912 : changing clock speed appears to have no effect. Paul N. is working very hard on this and explained to customer the impact of fixing it. Customer is okay with this so Paul will send the fixes to them. As far as sourcing, no idea - need to follow up on this so probably I will write a case to get it sourced.
*** Random thoughts ***
Sent some feedback to mgmt about defining End Of Life process. It's good that they're thinking about this, even though it's a painful subject for customers and difficult for the field people sometimes to talk about it with them. I agree though that something is needed - if anything it helps clarify what can be offered for older releases. But if we are not very aggressive about forcing upgrades on the base (i.e. Sun is quite aggressive about this and EOLs their old java stuff as soon as a new release is out), the product retirement process can really drag on for a long time.
Welcome to the test support/FAE blog
This is a proof-of-concept to try out the blogging idea for support purposes. Right now it is only internal but eventually (I hope) it would be a tool for communicating with customers in an external way.
This blog is not password-protected since it is hosted by blogspot.com . If the blog is hosted elsewhere password protection can be added. This is not going to be done anytime soon but perhaps in the future it will be password-protected and you'll have to go through me to get access.
This blog can only add comments by members. If you want to be a member send me an email through corp. email address.
What i'm planning to put on the blog:
- open issues (no customer names though since this is public)
- things I need
- observations for the week (tips, tricks etc)
- misc projects I'm trying to get going (hardware etc)
- personal updates (planned vacations, travel etc)
Other things that I would consider putting here are updates on FAEs in the US and their coordinates, as that's sure to be something of interest to customers.
Best Regards,
J. Mir
This blog is not password-protected since it is hosted by blogspot.com . If the blog is hosted elsewhere password protection can be added. This is not going to be done anytime soon but perhaps in the future it will be password-protected and you'll have to go through me to get access.
This blog can only add comments by members. If you want to be a member send me an email through corp. email address.
What i'm planning to put on the blog:
- open issues (no customer names though since this is public)
- things I need
- observations for the week (tips, tricks etc)
- misc projects I'm trying to get going (hardware etc)
- personal updates (planned vacations, travel etc)
Other things that I would consider putting here are updates on FAEs in the US and their coordinates, as that's sure to be something of interest to customers.
Best Regards,
J. Mir
free invisible web counter
