New ports wanted
ast
couple of items we would especially like to have. These are:
- Mplayer
- CDrecord
- PHP
I'm sufficiently interested in them that if someone signs up and does
the port quickly (say, a month), I will give the person a free copy of
the MINIX book personally autographed by me. If you are interested,
please contact me.
Another project (also worth an autographed book) is finishing the
PowerPC port. One of my masters students started it (see
http://www.minix3.org/doc/alting_thesis.pdf), but then based on his
work, we changed the structure of the system to make it easier to do
ports to other architectures, but this broke his port and it needs to
be patched up. The port was done on an Apple iBook G4, so anyone
attempting to do this project would need a G4 or something fairly
close.
Andy Tanenbaum
Thomas Bjorn Andersen
> Another project (also worth an autographed book) is finishing the
> PowerPC port. One of my masters students started it (see
> http://www.minix3.org/doc/alting_thesis.pdf), but then based on his
> work, we changed the structure of the system to make it easier to do
> ports to other architectures, but this broke his port and it needs to
> be patched up. The port was done on an Apple iBook G4, so anyone
> attempting to do this project would need a G4 or something fairly
> close.
Where would one find more information on this project? I am unable to
locate it on minix3.org, except for Ingmar Alting's thesis.
Specifically how is the system breaking and where is the current code?
Thomas
--
Thomas Bjorn Andersen - Quis custodiet ipsos custodes?
+++ATH
Thomas Bjorn Andersen
> Another project (also worth an autographed book) is finishing the
> PowerPC port. One of my masters students started it (see
> http://www.minix3.org/doc/alting_thesis.pdf), but then based on his
> work, we changed the structure of the system to make it easier to do
> ports to other architectures, but this broke his port and it needs to
> be patched up.
Where would one find more information on this? Specifically how is the
system breaking and where is the current code?
--
gmu...@cloudnet.com
wrote:
> ast <a...@cs.vu.nl> writes:
> >http://www.minix3.org/doc/alting_thesis.pdf), but then based on his
> > work, we changed the structure of the system to make it easier to do
> > ports to other architectures, but this broke his port and it needs to
> > be patched up.
>
> Where would one find more information on this? Specifically how is the
> system breaking and where is the current code?
alting_thesis.pdf does an excellent job of identifying the problem
areas.
Included in that work is the separation of the OS from platform
dependencies,
so that the platform-dependent code can be separated from the platform-
independent
code. Currently that is unseparated from the x86 hardware platform.
I found the code minix_source_3_1_1.tar.bz2 at the minix3 website
about 2 weeks
ago. That contains code in assembler *.s files. All of those files
need to be
checked and redesigned for a platform-independent implementation, and
then add the PPC platform alongside the x86.
Much of the code is in the subversion source tree. Perhaps some
pointers on
grabbing just a subportion of that tree would be helpful. Someone is
also
providing *.bz2 images, which provide excellent compression over
the .iso images.
These are accessable usually on weekends, in my experience. It would
be helpful
to be able to get weekly updates on minix_source_3_*_* as a .bz2 file.
with best regards,
Gerald
J.F. de Smit
> On May 13, 5:17 pm, Thomas Bjorn Andersen <tbaNOSPAM200...@gen-v.net>
> wrote:
>> ast <a...@cs.vu.nl> writes:
> I found the code minix_source_3_1_1.tar.bz2 at the minix3 website
> about 2 weeks
> ago. That contains code in assembler *.s files. All of those files
> need to be
> checked and redesigned for a platform-independent implementation, and
> then add the PPC platform alongside the x86.
Be advised that the assembler files are not the only place where
system-dependent code is located. The kernel process table stores a bunch
of CPU registers for each process and some of these are (of course) system
dependent. Parts of the system (like the signal mechanism) also do some
calculations with these registers (instead of just saving/restoring them
on context switches). Be sure to check those too!
Regards,
Jens
--
Jens de Smit
Student Computer Science | Vrije Universiteit Amsterdam
jfd...@few.vu.nl | http://www.few.vu.nl/~jfdsmit
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean
The-...@hotmail.com
> We are always interested in new drivers and ports, but there are a
> couple of items we would especially like to have. These are:
>
> - Mplayer
> - CDrecord
> - PHP
>
> I'm sufficiently interested in them that if someone signs up and does
> the port quickly (say, a month), I will give the person a free copy of
> the MINIX book personally autographed by me. If you are interested,
> please contact me.
>
> Another project (also worth an autographed book) is finishing the
> work, we changed the structure of the system to make it easier to do
> ports to other architectures, but this broke his port and it needs to
> be patched up. The port was done on an Apple iBook G4, so anyone
> attempting to do this project would need a G4 or something fairly
> close.
>
> Andy Tanenbaum
I'll take (another) crack at PHP. I had started working on it awhile
ago but dropped it to work on other stuff. I think that is what
prompted me to port libxml, but I can't really remember...
James T. Sprinkle - The Grue
Joerg Schilling
ast <a...@cs.vu.nl> wrote:
>We are always interested in new drivers and ports, but there are a
>couple of items we would especially like to have. These are:
>
> - Mplayer
> - CDrecord
> - PHP
>
>I'm sufficiently interested in them that if someone signs up and does
>the port quickly (say, a month), I will give the person a free copy of
Hi,
if you can give me a remote login on a minix system, I could give it a
try.
If the system is halfway POSIX, it should not be a big deal to make
all my software compile as it uses a highly portable structure.
Writing a SCSI generic adaptation layer may take a bit longer but
making it just compile is usually 1-2 hours for all my software (800,000
lines ~ 20 MB of C-code).
If you like to contact me in private, please send a mail to the Fraunhofer
mail address.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Philip Homburg
Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>If the system is halfway POSIX, it should not be a big deal to make
>all my software compile as it uses a highly portable structure.
>Writing a SCSI generic adaptation layer may take a bit longer but
>making it just compile is usually 1-2 hours for all my software (800,000
>lines ~ 20 MB of C-code).
At the moment, the IDE/ATAPI driver doesn't have any support for sending
SCSI commands from from user space.
Coming up with a good SCSI interface will be tricky because ioctls cannot
contain pointers (the 'safecopy' feature prevents driver from accessing
arbitrary buffer in user space. Hmm, thinking about it, you may be able
to pass a grant).
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Joerg Schilling
Philip Homburg <phi...@ue.aioy.eu> wrote:
>In article <5b8oueF...@mid.dfncis.de>,
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>If the system is halfway POSIX, it should not be a big deal to make
>>all my software compile as it uses a highly portable structure.
>>Writing a SCSI generic adaptation layer may take a bit longer but
>>making it just compile is usually 1-2 hours for all my software (800,000
>>lines ~ 20 MB of C-code).
>
>At the moment, the IDE/ATAPI driver doesn't have any support for sending
>SCSI commands from from user space.
The first step is always to port the software at all.
All my tools compile (if the basic port has been done) and link.
Programs like sformat, cdrecord, cdda2wav, readcd, ... will compile and allow
you to run them with e.g. -help, but as soon as you try to access a drive,
they will just print:
No local SCSI transport implementation for this architecture.
SCSI is more than just ATAPI, does miniy have USB, 1394, .... or other SCSI
transports? All SCSI transports should be put under a common SCSI umbrelly
driver.
>Coming up with a good SCSI interface will be tricky because ioctls cannot
>contain pointers (the 'safecopy' feature prevents driver from accessing
>arbitrary buffer in user space. Hmm, thinking about it, you may be able
>to pass a grant).
If you like to write a DVD at 18x write speed, you need a granted sustained
transfer speed of 25 MB/s. Also note that many DVD writers will not allow you
to write at all if you do not implement DMA.
I see no reason why forbidding pointers in ioctls should buy you any
safety.
Whether or not it is a risk to transfer from/to the kernel address space or
to the address apace of another process is just a matter of bound checks.
A halfway reasonable DMA implementation will prevent DMA overruns.
Giovanni
>
> No local SCSI transport implementation for this architecture.
>
> SCSI is more than just ATAPI, does miniy have USB, 1394, .... or other SCSI
> transports? All SCSI transports should be put under a common SCSI umbrelly
> driver.
>
I made the porting of the AHA1540 SCSI controller (from Minix2). It
is a very old ISA controller and the implementation is too specific
for that device, but it may be a starting point for implementing a
high level SCSI layer. If I can get free time I'll be working on that
but I'm not making any scheduling so, don't wait on it.
If you are interested look at:
http://giovanni.homelinux.net/development/index.html
Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 < http://giovanni.homelinux.net/ >
Ben Gras
> Where would one find more information on this? Specifically how is the
> system breaking and where is the current code?
The port was never really finished - for instance, it could only be
cross-compiled into from Linux, and the build system was hacked pretty
heavily to do so (gmake and gcc only, cross-compile only, hard-coded
paths for the cross-compilation setup, and so on). The port, such as it
was, was a good start, but rough and totally not unified with the old
world.
The ppc port "merge" consisted out of taking work the ppc port author
did to make a architecture dependent/independent split in the kernel,
and doing the i386 version of that split (the author had done the ppc
version, and in so doing, breaking i386).
To get the port again, the ppc port will have to be transplanted back
into the current code tree, following the current layout on the trunk
(and tracking it), without breaking the i386 'port' of course.
The good news is, the bits that I guess are normally the hard part in
porting to another architecture (getting low-level code like booting
and context switching to work), are done.
The code is in http://www.cs.vu.nl/~iaalting/pub/release.1.tgz .
The documentation is the author's thesis,
http://www.minix3.org/doc/alting_thesis.pdf
=Ben
Joerg Schilling
Giovanni <gfal...@inwind.it> wrote:
>> No local SCSI transport implementation for this architecture.
>>
>> SCSI is more than just ATAPI, does miniy have USB, 1394, .... or other SCSI
>> transports? All SCSI transports should be put under a common SCSI umbrelly
>> driver.
>>
>
>I made the porting of the AHA1540 SCSI controller (from Minix2). It
>is a very old ISA controller and the implementation is too specific
>for that device, but it may be a starting point for implementing a
>high level SCSI layer. If I can get free time I'll be working on that
>but I'm not making any scheduling so, don't wait on it.
>
>If you are interested look at:
>http://giovanni.homelinux.net/development/index.html
Well, it seems that this would "force" me to try to integrate
your driver into a self installed minix.
This is something I currently have defintive no time for.
For me it would be of interest to first compile all my sources.
I read that there are life CDs for Minix, but it is not clear whether these
CDs contain a complete build environment for me:
- A POSIX Shell (a classical Bourne shell is sufficient)
- All Tools needed for autoconf (configure) calls:
- sed
- rm
- egrep
- grep
- tr
- uname
- chmod
- expr
- false
- cat
- echo
- cp
- cmp
- mv
- ls
- [
- test
- A K&R or ANSI C-Kompiler
A portable Make Program is available: smake
It only requires that calls to execl("/bin/sh", "sh", "-ce", cmd, 0);
allow to run POSIX compliant shell commands.
I also don't know whether it would be simple to transfer the source
to the minix life CD enviroment.
Could you enlighten me?
Philip Homburg
Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>In article <ka48it9okv8b5hf352ac5toq55@inews_id.stereo.hq.phicoh.net>,
>Philip Homburg <phi...@ue.aioy.eu> wrote:
>>In article <5b8oueF...@mid.dfncis.de>,
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>If the system is halfway POSIX, it should not be a big deal to make
>>>all my software compile as it uses a highly portable structure.
>>>Writing a SCSI generic adaptation layer may take a bit longer but
>>>making it just compile is usually 1-2 hours for all my software (800,000
>>>lines ~ 20 MB of C-code).
>>
>>At the moment, the IDE/ATAPI driver doesn't have any support for sending
>>SCSI commands from from user space.
>
>The first step is always to port the software at all.
>All my tools compile (if the basic port has been done) and link.
>Programs like sformat, cdrecord, cdda2wav, readcd, ... will compile and allow
>you to run them with e.g. -help, but as soon as you try to access a drive,
>they will just print:
>
> No local SCSI transport implementation for this architecture.
My first step is usually to start with the hardest part of the problem.
Anyhow, VMware server or QEMU are probably the easiest platforms to run Minix
if don't have/want dedicated hardware.
>SCSI is more than just ATAPI, does miniy have USB, 1394, .... or other SCSI
>transports? All SCSI transports should be put under a common SCSI umbrelly
>driver.
At the moment there is no USB or 1394. And SCSI is limited to the AHA-1542,
which is not all that useful on modern hardware.
However, for cdrecord, I don't see any point a common SCSI layer.
>If you like to write a DVD at 18x write speed, you need a granted sustained
>transfer speed of 25 MB/s. Also note that many DVD writers will not allow you
>to write at all if you do not implement DMA.
That's a separate issue.
>I see no reason why forbidding pointers in ioctls should buy you any
>safety.
That depends on how soon IOMMUs become common.
>Whether or not it is a risk to transfer from/to the kernel address space or
>to the address apace of another process is just a matter of bound checks.
>A halfway reasonable DMA implementation will prevent DMA overruns.
Bus master DMA is very device specific. Anyhow, in future, on systems with
an IOMMU, the kernel will simply disallow DMA if you don't have permission.
Joerg Schilling
Philip Homburg <phi...@ue.aioy.eu> wrote:
>>The first step is always to port the software at all.
>>All my tools compile (if the basic port has been done) and link.
>>Programs like sformat, cdrecord, cdda2wav, readcd, ... will compile and allow
>>you to run them with e.g. -help, but as soon as you try to access a drive,
>>they will just print:
>>
>> No local SCSI transport implementation for this architecture.
>
>My first step is usually to start with the hardest part of the problem.
>
>Anyhow, VMware server or QEMU are probably the easiest platforms to run Minix
>if don't have/want dedicated hardware.
I do not have VMware.
>>SCSI is more than just ATAPI, does miniy have USB, 1394, .... or other SCSI
>>transports? All SCSI transports should be put under a common SCSI umbrelly
>>driver.
>
>At the moment there is no USB or 1394. And SCSI is limited to the AHA-1542,
>which is not all that useful on modern hardware.
>
>However, for cdrecord, I don't see any point a common SCSI layer.
Cdrtools are based on a generic device independend SCSI pass through library.
If a platform does not support a common SCSI layer, adding support would be
adding a dirty hack.
>>I see no reason why forbidding pointers in ioctls should buy you any
>>safety.
>
>That depends on how soon IOMMUs become common.
How is that related?
Any DMA controller I am aware of implements an interrupt when the counter
is completed. It should be fairly easy to prevent unwanted memory access
this way.
The IOMMU is a part of the Sun DVMA patent, do you know when the Sun DVMA
Patent will expire?
Philip Homburg
Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>In article <slflk9qg3906ue4sufhr904sf0@inews_id.stereo.hq.phicoh.net>,
>Philip Homburg <phi...@ue.aioy.eu> wrote:
>>Anyhow, VMware server or QEMU are probably the easiest platforms to run Minix
>>if don't have/want dedicated hardware.
>
>I do not have VMware.
VMware server is free (as in free beer).
>>However, for cdrecord, I don't see any point a common SCSI layer.
>
>Cdrtools are based on a generic device independend SCSI pass through library.
>If a platform does not support a common SCSI layer, adding support would be
>adding a dirty hack.
Yes, SCSI pass through support has to be added to the SCSI driver, IDE/ATAPI
driver, etc. That still has to be done. The assumption is that the person
porting cdrecord will do that.
>>>I see no reason why forbidding pointers in ioctls should buy you any
>>>safety.
>>
>>That depends on how soon IOMMUs become common.
>
>How is that related?
With bus master DMA, a driver can corrupt arbitrary memory. There is no way
that generic code can verify whether or not the driver is programming the
hardware correctly.
So, the solution is to have some other part of the system program the IOMMU.
If the driver doesn't have permission to touch a specific part of memory,
it won't get access.
>The IOMMU is a part of the Sun DVMA patent, do you know when the Sun DVMA
>Patent will expire?
Both Intel and AMD promised IOMMUs. I don't know about the patents.
Joerg Schilling
>In article <5bfv0aF...@mid.dfncis.de>,
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>In article <slflk9qg3906ue4sufhr904sf0@inews_id.stereo.hq.phicoh.net>,
>>Philip Homburg <phi...@ue.aioy.eu> wrote:
>>>Anyhow, VMware server or QEMU are probably the easiest platforms to run Minix
>>>if don't have/want dedicated hardware.
>>
>>I do not have VMware.
>
>VMware server is free (as in free beer).
It does not run on Solaris.
>>Cdrtools are based on a generic device independend SCSI pass through library.
>>If a platform does not support a common SCSI layer, adding support would be
>>adding a dirty hack.
>
>Yes, SCSI pass through support has to be added to the SCSI driver, IDE/ATAPI
>driver, etc. That still has to be done. The assumption is that the person
>porting cdrecord will do that.
When I did write the scg driver in 1986, this was new. Today, I would asume that
this is a OS basic feature.
I can help you with the minimum requirements for the call interface.
I can help with writing a low level adaptation layer for libscg and I
can help with verifying the correctness of the interface using "scgcheck"
but I would asume that someone else writes the driver for the OS.
>>>>I see no reason why forbidding pointers in ioctls should buy you any
>>>>safety.
>>>
>>>That depends on how soon IOMMUs become common.
>>
>>How is that related?
>
>With bus master DMA, a driver can corrupt arbitrary memory. There is no way
>that generic code can verify whether or not the driver is programming the
>hardware correctly.
>
>So, the solution is to have some other part of the system program the IOMMU.
>If the driver doesn't have permission to touch a specific part of memory,
>it won't get access.
In this case you just need to trust the code that programms the IOMMU.
This does not look like a real advantage.
>>The IOMMU is a part of the Sun DVMA patent, do you know when the Sun DVMA
>>Patent will expire?
>
>Both Intel and AMD promised IOMMUs. I don't know about the patents.
Sun invented them and shipped the first IOMMUs ~ 1985. How many years does
a patent lasts in the USA?
Philip Homburg
Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>When I did write the scg driver in 1986, this was new. Today, I would asume that
>this is a OS basic feature.
So far, nobody added support for generic SCSI to Minix.
>I can help you with the minimum requirements for the call interface.
>I can help with writing a low level adaptation layer for libscg and I
>can help with verifying the correctness of the interface using "scgcheck"
>but I would asume that someone else writes the driver for the OS.
This is what I came up with for Minix-vmd
<http://www.minix-vmd.org/current/vmd/include/sys/scsi.h>
(Starting with 'struct scsicmdx')
Any comments?
However, for Minix3, the pointers have to be placed with grants, and the
drivers has to be informed about the user process' endpoint.
>In this case you just need to trust the code that programms the IOMMU.
>This does not look like a real advantage.
It is, because the code for programming the IOMMU has to be written once
(or a few times) of each platform, whereas each device driver (just about
every ethernet card, 3 USB interfaces, Firewire, SCSI drivers, IDE/ATAPI/
enhanced-SATA) all program bus-master DMA devices.
mark south
>>Both Intel and AMD promised IOMMUs. I don't know about the patents.
>
> Sun invented them and shipped the first IOMMUs ~ 1985. How many years does
> a patent lasts in the USA?
It used to be 25 years, although they have probably extended that to
several centuries by now. If Sun was shipping IOMMUs in 1985, they
probably had the patent for a couple years before that already.
Disclaimer: IANAPL.
Joerg Schilling
Philip Homburg <phi...@ue.aioy.eu> wrote:
>In article <5bg4onF...@mid.dfncis.de>,
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>When I did write the scg driver in 1986, this was new. Today, I would asume that
>>this is a OS basic feature.
>
>So far, nobody added support for generic SCSI to Minix.
>
>>I can help you with the minimum requirements for the call interface.
>>I can help with writing a low level adaptation layer for libscg and I
>>can help with verifying the correctness of the interface using "scgcheck"
>>but I would asume that someone else writes the driver for the OS.
>
>This is what I came up with for Minix-vmd
><http://www.minix-vmd.org/current/vmd/include/sys/scsi.h>
>(Starting with 'struct scsicmdx')
>
>Any comments?
What you need is the following:
- SCSI cdb
- CDB len
- Data addr
- Data len
- Data direction (from/to/none - none could be len == 0)
- DMA residual count (data len may be modified)
- SCSI Status Byte for CMD
- Auto-sense buffer
- Auto-sense len (and real sense data amount) must be at least 18
- Auto-sense status byte (nice to have)
- Timeout for SCSI command
- SCSI Command trasfer status
This needs to be at least:
- Transfer OK
- Could not send CDB
- Retryable (a.g. Target busy)
- Timeout occured
BTW: the residual count should be able to report DMA overruns.
>However, for Minix3, the pointers have to be placed with grants, and the
>drivers has to be informed about the user process' endpoint.
What does this mean?
>>In this case you just need to trust the code that programms the IOMMU.
>>This does not look like a real advantage.
>
>It is, because the code for programming the IOMMU has to be written once
>(or a few times) of each platform, whereas each device driver (just about
>every ethernet card, 3 USB interfaces, Firewire, SCSI drivers, IDE/ATAPI/
>enhanced-SATA) all program bus-master DMA devices.
In Solaris, there is a generic DMA setup interface that programms the IO/MMU
and maps pages and calls back to the trusted DMA Chip code.
Markus E Leypold
> In article <umrs4hbmfoharurcf9veonkgo6@inews_id.stereo.hq.phicoh.net> you write:
>>In article <5bfv0aF...@mid.dfncis.de>,
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>In article <slflk9qg3906ue4sufhr904sf0@inews_id.stereo.hq.phicoh.net>,
>>>Philip Homburg <phi...@ue.aioy.eu> wrote:
>>>>Anyhow, VMware server or QEMU are probably the easiest platforms to run Minix
>>>>if don't have/want dedicated hardware.
>>>
>>>I do not have VMware.
>>
>>VMware server is free (as in free beer).
>
> It does not run on Solaris.
That is true. But neither does Minix :-).
>>>Cdrtools are based on a generic device independend SCSI pass through library.
>>>If a platform does not support a common SCSI layer, adding support would be
>>>adding a dirty hack.
>>
>>Yes, SCSI pass through support has to be added to the SCSI driver, IDE/ATAPI
>>driver, etc. That still has to be done. The assumption is that the person
>>porting cdrecord will do that.
> When I did write the scg driver in 1986, this was new. Today, I would asume that
> this is a OS basic feature.
Now, now. Minix 3 is not complete yet. Therefore the call for ports, I
assume, some of them entailing that parts of the necessary kernel
infrastructure must be created first.
> I can help you with the minimum requirements for the call interface.
> I can help with writing a low level adaptation layer for libscg and I
> can help with verifying the correctness of the interface using "scgcheck"
> but I would asume that someone else writes the driver for the OS.
>>>The IOMMU is a part of the Sun DVMA patent, do you know when the Sun DVMA
>>>Patent will expire?
>>
>>Both Intel and AMD promised IOMMUs. I don't know about the patents.
>
> Sun invented them and shipped the first IOMMUs ~ 1985. How many years does
> a patent lasts in the USA?
50? IANAL, though.
Regards -- Markus
Joerg Schilling
Markus E Leypold
<development-2006-8...@ANDTHATm-e-leypold.de> wrote:
>>>Yes, SCSI pass through support has to be added to the SCSI driver, IDE/ATAPI
>>>driver, etc. That still has to be done. The assumption is that the person
>>>porting cdrecord will do that.
>
>> When I did write the scg driver in 1986, this was new. Today, I would asume that
>> this is a OS basic feature.
>
>Now, now. Minix 3 is not complete yet. Therefore the call for ports, I
>assume, some of them entailing that parts of the necessary kernel
>infrastructure must be created first.
This is what I did believe to be 10 years ago....
At that time, I thought that *BSD make would be able to deal with
the Schily makefilesystem once it had a non-broken implementation
for pattern macro expansions.
A few years ago, we did fix this bug and found that *BSD make has
paradigms that are completely different from the ones found in
other make tools and in the POSIX standard. So it was not possible
to use *BSD make.....
For this reason, it is always a good idea to first do the simple job
in order to find out whether there are other problems.
Markus E Leypold
> In article <fpbqgdq...@hod.lan.m-e-leypold.de>,
> Markus E Leypold
> <development-2006-8...@ANDTHATm-e-leypold.de> wrote:
>
>>>>Yes, SCSI pass through support has to be added to the SCSI driver, IDE/ATAPI
>>>>driver, etc. That still has to be done. The assumption is that the person
>>>>porting cdrecord will do that.
>>
>>> When I did write the scg driver in 1986, this was new. Today, I would asume that
>>> this is a OS basic feature.
>>
>>Now, now. Minix 3 is not complete yet. Therefore the call for ports, I
>>assume, some of them entailing that parts of the necessary kernel
>>infrastructure must be created first.
>
> This is what I did believe to be 10 years ago....
:-)
This is Minix 3 we're talking about. As I see it, a major overhaul has
occured and the scope of the project has shifted: Minix 2 was just
POSIX 1 and one of the aims (AFAIR) was to let it run properly even on
8086 in real mode. Minix 3 still needs a lot of work and aims to the
current main stream hardware, but I would be surprised if it even
qualifies as POSIX 3 even remotely at the moment.
I think you've to get the state of Minix 3 in proper perspective at
the moment.
> At that time, I thought that *BSD make would be able to deal with
> the Schily makefilesystem once it had a non-broken implementation
> for pattern macro expansions.
> A few years ago, we did fix this bug and found that *BSD make has
> paradigms that are completely different from the ones found in
> other make tools and in the POSIX standard. So it was not possible
> to use *BSD make.....
:-).
I know your plight.
> For this reason, it is always a good idea to first do the simple job
> in order to find out whether there are other problems.
Quite right. I find your approach (to port your build system + other
software first) quite reasonable. My comment referred to your "scg
driver [...] I would asume that this is a OS basic feature". Minix
hardly has any hardware support (see network interface cards)
(hopefully: yet), not to talk about some driver abstraction layers and
features. I think that is primarly a question of man power,
development is not as fast as it is in other operating systems. You've
to consider that Minix 3 is now ~2 years old (AFAIR).
Regards -- Markus
Joerg Schilling
OK, so what do you recommend to do?
Is there a machine for remote login?
Will a life CD work and allow transfer the needed data?
Markus E Leypold
> In article <pvirajz...@hod.lan.m-e-leypold.de>,
> Markus E Leypold
> <development-2006-8...@ANDTHATm-e-leypold.de> wrote:
>
>>> For this reason, it is always a good idea to first do the simple job
>>> in order to find out whether there are other problems.
>>
>>Quite right. I find your approach (to port your build system + other
>>software first) quite reasonable. My comment referred to your "scg
>>driver [...] I would asume that this is a OS basic feature". Minix
>>hardly has any hardware support (see network interface cards)
>>(hopefully: yet), not to talk about some driver abstraction layers and
>>features. I think that is primarly a question of man power,
>>development is not as fast as it is in other operating systems. You've
>>to consider that Minix 3 is now ~2 years old (AFAIR).
> OK, so what do you recommend to do?
I wouldn't dare "recommend" :-). I'd just say, that if you want to get
cdrecord going at Minix, you'll have to dive into writing the
necessary driver parts too (or find somebody who teams with you and
does this part of the work).
> Is there a machine for remote login?
Unfortunately not yet. I'd hope somebody at VU would get you some
:-). I (not being part of the Minix team, mind you) could try to
arrange for a login (but that will take time) on a virtual machine,
but (a) if you're satisfied with a virtual machine, you could take
QEMU yourself and (b) I'm sure, to create the necessary driver parts,
you'd have to have real hardware.
> Will a life CD work and allow transfer the needed data?
Try it. Minix 3 comes on a live CD. Transferring data is done with
isoread or dosread/doswrite via a FAT file system (or probably over
the network). Having a common FAT scratch partition is a good idea
then. But if you go for creating a new partition you can as well make
too and install Minix to harddisk properly.
Come on Joerg: Even I got a lot of vintage hardware standing around
here (and due to having to move much too often during the last years
I've had to cull that mercilessly). Just get yourself a K6 400 or a
3xx Mhz Pentium, even borrow it from someone for 4 weaks, including a
>1GB Hard disk and you're in business. Seems to me the easiest way and
probably much less effort than arranging for remote logins.
Regards -- Markus
Markus E Leypold
> In article <pvirajz...@hod.lan.m-e-leypold.de>,
> Markus E Leypold
> <development-2006-8...@ANDTHATm-e-leypold.de> wrote:
>
>>> For this reason, it is always a good idea to first do the simple job
>>> in order to find out whether there are other problems.
>>
>>Quite right. I find your approach (to port your build system + other
>>software first) quite reasonable. My comment referred to your "scg
>>driver [...] I would asume that this is a OS basic feature". Minix
>>hardly has any hardware support (see network interface cards)
>>(hopefully: yet), not to talk about some driver abstraction layers and
>>features. I think that is primarly a question of man power,
>>development is not as fast as it is in other operating systems. You've
>>to consider that Minix 3 is now ~2 years old (AFAIR).
>
> OK, so what do you recommend to do?
>
> Is there a machine for remote login?
> Will a life CD work and allow transfer the needed data?
Ping!
Hi Joerg,
How did it work out? Are you still at it, or have you given up the
idea?
Regards -- Markus