Re: ELKS Development/FAQ Questions

Phil Goembel
2003-08-01T14:05:54Z

[-- Attachment #1: Type: text/plain, Size: 5713 bytes --]

Hi again Riley,

Thanks for taking the time to reply.

On Thu, 2003-07-31 at 01:01, Riley Williams wrote:
> Hi Phil.
>
> > 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.

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 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.).

> > 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?

Is there an RPM package for the latest version?

If not, would there be any interest in having one?

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).

> 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?

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.

> 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 toolchain better, I
will set things up so that "make configure" or "./configure"
will set up macros with the correct paths for each tool?

> > I will gladly update the ELKS FAQ with any answers you can
> > give me.
>
> Hopefully, the above will help you.
>
> Best wishes from Riley.
> ---
> * Nothing as pretty as a smile, nothing as ugly as a frown.

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

Regards,
Phil

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]