Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Interview with Pavel Fedin
(Interview conducted by Olivier Tigréat - October 2011)
|
|
Current pace of AROS' development can be perceived on www.ohloh.net/p/aros.
Though as can be seen here, the Russian developer
Pavel "Sonic" Fedin is alone responsible for more than 3400 commits in eleven years, while the other four most important
AROS contributors are inactive or almost since five years (apart of Georg Steger who was still active one year ago)...
One can then see how much Pavel is important in current AROS evolution.
 Can you tell us about you?
Family? Non-computers hobbies? Work? What is the place of AROS in all that?
I'm 32 and I have a wife. I like everything technical. My first interest from the early
childhood was electrics and electronics. I have engineer degree (it's
complete russian 5-years high education, between bachelor and master),
in electronics design. However I work as a software developer, because
there's actually no hardware design in Russia.
Could you tell us about your
motivations when you bought your first Amiga? And why such a machine in 1999: wasn't it more out-of-date than "alternative"?
And why to search for "alternative" in the first place?
I always liked alternative things. Don't know why. Perhaps because i
like knowledge, and I like investigating. It's neither interesting nor
exciting to deal with Windows PCs, because they are dedicated to
trivial tasks like office word processing and Internet browsing.
And what led you to the Pegasos II
and MorphOS?
Wish to upgrade.
I guess some MorphOS
users would like to know if your BootX project of a bootstrap for Mac OS X on Pegasos reached an usable state?
No.
And have you had the
opportunity to improve your Fireworks stack (FireWire)?
No. Since PowerPC architecture actually ceased development, I lost
interest. I still keep my Pegasos just because I feel sorry to drop
it. FireWire is also dead by itself, superseded by USB. And I have no
hardware. I had DV camera donated for the project, but it failed, and
I was never able to repair it.
And AROS: how did it got your
interest?
When I first leaned about AROS, I liked the idea. First, I had a
possibility to run Amiga-compatible OS on both machines (I had a
Pentium I PC built from srap parts back then, to run MS Office).
Second, I had m68k Mac laptop, and it seemed a nice idea to have a
portable Amiga system.
We owe you the ability
to drag overlapping screens, like allowed on original Amiga. Can you describe how you implemented it?
Of course. I added ShowViewPorts method to graphics driver, which gets a
singly-linked list of bitmaps. This list reprsents z-ordered bitmaps
to display.
A bitmap also has XOffset and YOffset attributes, which a driver-side
representation of ViewPort offsets. It's up to the driver to handle all this.
A software implementation is a graphics.library plug-in. It intercepts three points:
- 1. LoadView()
- 2. ScrollVPort()
- 3. Bitmap update
Composition plug-in simply opens own screen, and mirrors changes in
composited bitmaps on it. There's no need to do something special with
Intuition's input because the simulation sits on a very low level, and
AROS Intuition handles screen drag natively.
Do you plan to continue to
improve the graphics/intuition parts in the future?
Yes. No time for now, but there are plans. For example I want to
implement a framework for building a mirrored display driver.
If I understood correctly,
the dragging ability is allowed by the use of a sort of a "master" bitmap in front of all...
It's not in front. It's just the only bitmap. Display drivers that don't support hardware composition, have only
one bitmap on display.
...in which real screen bitmaps are
composited at the position the user want them to be. If so, could this "master" bitmap be used to render some sort of "super-windows"
that would have a similar behaviour like DashBoard widgets on Mac OS X: they would always be in front of whatever screen is currently
shown?
It could, but:
- 1. This "master" bitmap exists only when the composition is active (i.e. there's more than one bitmap on the screen).
- 2. It's slow, because every drawing operation has to be reflected on the composited screen.
- 3. This can be much simpler done on Intuition level using regular windows. There's no need to dive so deeply for that.
Could there be a special condition,
perhaps limited to hardware-accelerated drivers, where the screens could be scaled (something like graphics.library/BitMapScale()) in
the said-"master"-bitmap, to be all visible at the same time, as what Mac OS X does with windows in Exposé?
Yes, there could. One can try to expand the composition plug-in into subsystem allowing different representations.
Could the screens be rendered in real time?
They are rendered in real time.
Have you though about the requirements
of implementing real transparency abilities on windows-level (layers?), like what MorphOS and AmigaOS 4 both already allow?
I thought about this. However I lack time and knowledge. I have never been an artist, so graphics (including programming it) is completely
alien to me. I very poorly understand GL.
You have done an huge work on merging
various i386 kernel codes and they are now almost on par (and in fact improving) with Sam's kernel, which is state-of-the-art of Michal
Schulz's works. What will be the benefits of this work?
The main of benefits is reduced difference between kernels, and high
percent of code reuse. This means that every change is well tested,
since it's emerged into all platforms. Like new alerts and stack
backtrace.
You have proposed for the ACPI-phase 1
bounty. What are the expected benefits for AROS on supported platforms?
Phase 1 is a small step towards all this, however, ACPI lets to:
- 1. Use several CPU cores.
- 2. Use IOAPIC interrupts. Some machines (Intel Mac mini for example) are slow with AROS without this, because all devices share IRQ0.
- 3. Use high-precision timers, allowing better time measurement.
Do you think AROS could be improved
to use multicore processors soon? Can you share your ideas on this topic?
Yes it could. First of all it could be extended with exec-alike
library which would allow to run dedicated tasks on secondary CPU
cores (PowerUP-alike approach). This is much easier to implement than
full SMP (because the new library is legacy-free), but still useful
(for example video players and coders could support this).
I know you have thought about memory
protection too... Can you talk about it?
Yes, I can.
Exec pools are already MP-ready. They are rewritten to use chunks of
fixed size. There's no more 'thresh size', and puddle size is always
a multiple of CPU page size. If some large block is allocated
(larger than puddle size), an enlarged puddle is allocated. This
is still a puddle, so its tail is reused for small allocations.
This allows to use pools to break up memory pages (obtained from
kernel's allocator) into variable-length blocks.
AllocMem() with memory protection active is supposed to be just
AllocPooled() from system default pool.
Kernel's allocator exists in draft version and is not used yet. I
have no time to test it well. Additionally, with current default pool
implementation AllocMem() would be slow, because the pool would be
mixed. The same pool would contain chunks with different flags. Pool
manager supports this, but it will be slow. I am thinking on how to
improve it.
What did I forget? ;-)
Don't know.:)
What would you like to add?
Don't know, really. I lack time and phantasy...
You have often improved AROS with parts
closely inspired from MorphOS inners. What are your relations with MorphOS devs? What parts of its code have you seen, and if so how come
you have seen it?
I have no relations with MorphOS devteam. And have seen only public
(or leaked) code. If you remember, there was some code leak as a
result of internal conflict in MorphOS team. I released some
unofficial MorphOS updates back then, based on leaked sources.
Mingw32-hosted is a lot more usable than
it was in early times, but it still often swallows some characters typed on the keyboard, and it still (very rarely though) hangs randomly.
Will you be able to come back to it?
Yes, I will. Don't know when, but I want to. In fact I am using this
version myself, to install newly built files to my laptop's
native AROS partitions.
I already know what to do with keypresses. I also sometimes
experience freezes, but haven't found origin yet.
Could you briefly explain how one can
build AROS on Windows?
The same as on any other platform. "configure" then "make". MinGW is needed.
Now that AROS runs on ARM
portable devices thanks to your (and Michal's) amazing work, is it easy for devs to port applications
on those systems? Is there one single sort of ARM executables, as there is a single sort of i386 executables running on all flavours?
Yes, there is a single sort of ARM executables.:) ARMv6 CPU, VFP FPU, softfloat ABI.
Other flavors are proposed (like ARMv7 + Neon hardfloat), but currently this is not in production.
Android port seems to be close to a very
usable stage. What about IOS port?
iOS is a very restrictive system. For example it's impossible to
allocate a memory with read-write-execute access. It can be either
read-execute or read-write. This way, memory protection support is
mandatory for AROS to work on iOS.
I came back to this port now, and implementation of display driver is
in progress. I test it on simulator, which uses i386 architecture and
is free from memory restrictions. When I'm done with this, i'll
complete memory protection.
|
