RE: ELKS Development/FAQ Questions

["Riley Williams" <Riley@Williams.Name>]

Hi Phil.

 > Thanks for taking the time to reply.

NP.

 >>> Ok. I'd like to help with the ELKS website, and with the
 >>> documentation. But my main interest is to help with
 >>> development of the ELKS code.
 >>>
 >>> I have virtually no experience with the Linux development
 >>> environment, but I do have experience in cross-development
 >>> for embedded microprocessor systems (in DOS and Win32
 >>> environments)

 >> You need to remember here that the tools used for ELKS are of
 >> no use for Linux even though they are for the same processor.
 >> This is because ELKS only uses the x86 processors in what is
 >> called "Real Mode" since the 8086 that ELKS is primarily aimed
 >> at has no other mode, whereas Linux uses it exclusively in
 >> "386 Protected Mode" and, whilst the actual opcodes are mainly
 >> the same, the environment they are used in, and the assumptions
 >> the tools need to make, are completely different.

 > I understand the difference between "Real" mode and "Protected"
 > mode. That is one reason why I have some reservations about
 > mixing "Real" mode development tools into the same directories
 > as the native "Protected" mode tools and libraries.

There's actually no reason to have reservations about that, as it's
no more of a problem than having the binaries for ftp and telnet in
the same directory - both are protocols used over the Internet, but
have major differences from each other.

 > But, as I have seen from recent posts to the ELKS list, it might
 > be worthwhile to add this to the FAQ. I am also thinking it might
 > be helpful to explain why programming for the x86 "Real" mode is
 > so different from programming for other MMU-less architectures
 > (like the "Dragonball", e.g.). 

There could certainly be reasons for adding a pointer to one of the
many excellent websites about the differences between the real and
protected modes on the x86 family of processors, but I can't see
any reason for rewriting what's already out there.

 >>> I am trying to follow the FAQ in setting up the environment
 >>> so that I can compile the ELKS kernel, but have almost
 >>> immediately run into a problem.
 >>>
 >>> The FAQ is telling me to install the Dev86 package in the
 >>> root (/) directory. I don't want to do this, and I see no
 >>> reason that I should have to.
 >>>
 >>> I would much rather do all of my cross development in my
 >>> home directory, with my standard user privileges, not root
 >>> privileges. I feel this would be much safer, especially
 >>> since I already have some tools installed that have the same
 >>> name as the Dev86 tools. I don't know where they came from,
 >>> and I'd rather not clobber them.

 >> Have you ever installed the bin86 package? If so, that's an old
 >> version of the dev86 package, and installing the dev86 package
 >> will just install more recent versions of all of the same tools.

 > Actually, I appear to have dev86-0.15.5 installed. Looks like I
 > installed it as an RPM package about 2 years ago. Is this version 
 > too old?

That's newer than the version I'm using - I show dev86-0.15.0-2 here,
a Red Hat Linux 6.2 based system with most updates already applied.

 > Is there an RPM package for the latest version?

I'm just checking ftp://updates.redhat.com/6.2/en/os/ to see whether
any updates show thereon - OK, none showing, so presumably nothing on
Red Hat's site. I'm not sure offhand where the dev86 development site
is, but there's almost certainly an RPM for the latest version there.

 > I have created some simple RPM packages before, and am also intent
 > on learning how to create Debian packages (when I said I'm "virtually
 > ignorant" above, I was referring to setting up and troubleshooting
 > problems in a GNU tool-chain - I'm usually at a complete loss when
 > things like "make configure", "make dep", and "make" start spewing
 > out errors).

That is understandable.

 >> The Linux C compiler is "gcc" and the associated assembler and
 >> loader are "as" and "ld" respectively. The ELKS compiler is "bcc"
 >> and its associated assembler and loader are "as86" and "ld86"
 >> respectively. As a result, it is not possible to interfere with
 >> one by upgrading the tools associated with the other.

 >>> Is it possible to set up everything in ~/? If so, how
 >>> is it done? What reasons are there for me NOT to do it that
 >>> way? If I can't set up everything in ~/, please explain why?

 >> From a purely practical viewpoint, as long as the relevant tools
 >> are in a directory in the PATH environment variable, and no
 >> earlier directory in that variable contains tools with the same
 >> name, it doesn't actually matter where they are. However, it is
 >> NOT a good idea to put a user directory ahead of the system
 >> binary directory.

 > I've read before that it is a bad idea to put a user directory
 > ahead of the system binary directories, but never an explanation.
 > Why is this a bad idea?
 >
 > Does it have something to do with the possibility of a malicious
 > third-party placing Trojans in the user's directories with the same
 > name as a system binary?

Not even that - simply as a result of ignorance, it's possible to create
a program with the same name as a standard program. If you have the PATH
with ./bin in front of the system directory with that standard command
in it, then ANY standard shell script that makes use of the said command
will accidentally use your version rather than the standard one.

As an example of how widespread this is, I just ran the following on
my development system...

	file /usr/bin/* | fgrep -iw script

...and found 285 shell scripts in that one system binary directory...

 > One of my reasons for wanting to install the tools in my user
 > directory was because I thought that it would be safer than
 > installing code of uncertain origin in the system binary directories.
 > I don't like using root privileges if I don't have to, but I can
 > change my habits if there are compelling reasons to do so.

As far as the dev86 package is concerned, the only reason to have more
than one copy of it installed on your system is if you are helping to
debug the existing version and create a new version.

 >> The standard place to put personal binaries is in the directory
 >> ~/bin with the same directory appended to the END of the standard
 >> PATH variable with an entry of...
 >> 
 >>	if [ -d ~/bin ]; then
 >>		export PATH=${PATH}:~/bin
 >>	fi
 >> 
 >> ...in your ~/.bashrc file. This ensures that the said directory
 >> is only added if it actually existed when you logged on.

 > My plan was to have a script to set up a different development
 > environment (tool chain) depending what project I wish to
 > work on. Then I normally would not have ~/bin in my PATH
 > except in the one terminal window I'm using for builds.
 > Or maybe, once I understand the GNU tool chain better, I
 > will set things up so that "make configure" or "./configure"
 > will set up macros with the correct paths for each tool?

I have to admit that sounds like a lot of work for next to no gain
to me, but you know your setup better than I ever can...

 >>> I will gladly update the ELKS FAQ with any answers you can 
 >>> give me.

 >> Hopefully, the above will help you.

 > Everything you've provided has been a help. Thank you.

Thanks for that.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003