Re: Call for Foundation-supported Project Ideas

I am not a part of this discussion , and the problem is not affecting me .
But ... Such situations really are causing significant  pain in my soul .

Why ?

( I am a graduate of Mathematics , In our work every claim requires a PROOF
, not
words of a BIG one , whether she/he is me or any other one . )


I graduated in 1974 and started as a "System Analyst and Designer" job in
Hacettepe University ( Ankara , Turkey ) . In our school , the computer was
IBM System 360 with 64 KILO bytes . In Hacettepe Data Processing Center ,
the computer
was a Burroughs B3500 with  128 KILO bytes ( called in that system as 256
KILO digits ) .




https://en.wikipedia.org/wiki/Burroughs_Medium_Systems
Burroughs Medium Systems

https://en.wikipedia.org/wiki/Burroughs_MCP
Burroughs MCP




I front of its console ( Commands may be differently written ) :

--- stop  n  <---- Number of multi-tasked job
--- .
--- .
--- .
--- start  n  <---- Number of multi-tasked job
--- .
--- .
--- .
--- set priority n as  m
 ...

A company of Hacettepe University was using the computer during nights .
When they were starting around  18:00 :


--- load  /  into tape in { cluster unit of }  n   ( 1 , 2 , 3 ,or 4 )



--- remove  /    <----- All of the contents ( written as  /  ) of the  100
MEGA bytes
                                Hard disk larger than a caravan type
automobile .

--- load tape from { cluster unit of }  n   ( 1 , 2 , 3 ,or 4 )

    A short time later , ALL of the MCP ( Master Control Program ) and data
    was loaded into the hard disk and ALL of the possible work began .

Around  1979 , a new mainframe arrived to Beytepe campus of Hacettepe :

Burroughs B6700  with 2 ( TWO )  MEGA bytes memory .




https://en.wikipedia.org/wiki/Category:Burroughs_mainframe_computers
Category:Burroughs mainframe computers


https://en.wikipedia.org/wiki/Category:High-level_language_computer_architecture
Category:High-level language computer architecture


https://en.wikipedia.org/wiki/Burroughs_large_systems
Burroughs large systems



Around  1980 years , one engineer working for a large USA company made a
remark , approximately , :  "... Optimization of a very large Fortran
program such as
2000 lines is a very difficult task . ... "

Some of my mathematical analysis programs much larger than 2000 lines were
developed
and executed on this computer .

It is not easy to develop such a large program  without possible run time
error(s) .

Burroughs B6700 computer ( multi-tasked ) was using "print spooling" .
In output of program , after banner about user name and some other
information
about the job , was listing a stack trace ( approximately in the following
structure ,
the listing is not the exact reproduction ) :

Run time error : n
has occurred in line : m  in routine :  name

called by routine :   name     from line :   k
called by routine :   name     from line :   k

  .
  .
  .

called by main :   name   from line :   k


Now the year is 2022 . You know what is the level of maturity or usability
or
other features of existing systems . The cpu speed is around 3 GIGA Herz .
The memory sizes are {  4 or 8 or 16 or 32 or 64 or 128 or 256 ... ) GIGA
Bytes ...
The job done is ... : I do not know anything except  fancy or fantastic
screen paints or other useless things excluding facilities like the
examples given above ...



Please  NEVER think that I am blaming our very valuable contributors .
Contrary to
such a disgusting behavior  I  am very indebted to them for their efforts (
means
using their a part of very holy life time for the benefit of humanity ) .

I know the difficulty of working in such a time : When it is understood
that a pandemic
has started , my official medical doctor called me to say :

"Never go outside !   It is very dangerous for you ... " .

Since at the beginning of 2020 February I am in isolation .
The other people are not better than me with respect to their jobs ,
dangers for their families and themselves .



At that , we need ways  to maximize  productivity of our contributors and
users
of FreeBSD  by minimizing  waste of their time ( ... ) and resources .

How ?

This is a different story outside of this thread .


I am very sorry to waste your time .

With my best wishes for your future and your work .




Mehmet Erol Sanliturk





On Wed, Jan 5, 2022 at 3:17 PM Stefan Blachmann <sblachmann@gmail.com>
wrote:

> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> > 15 or 20 years [...]
> > main reason laptops stopped suspending in the early 2000s... [...]
> > And the INT xx interface is unavailable on amd64 after we
> > enter long mode
>
> First, you mentioned a hacking session in the "early 2000s".
> This makes me wonder whether you might mistake some other thing from
> the distance of time, as UEFI was no real thing until ~2010, and was
> never a thing on platforms other than amd64 also. Suspend/resume on
> FreeBSD only appeared much later, too.
>
> Second, there is kernel functionality to call real mode interrupt
> handlers from long mode, which manage switching to real mode and back.
> Just an example, these are being used by vt (via vesa.ko) to switch vesa
> modes.
>
> So I do not see why this real mode access infrastructure could not
> also be used to make a call to C000:(PCI PROM Programming interface
> code offset), or the respective segment address where the actual VGA
> BIOS is, to have it initialize the int 10h interface handler, if a
> hybrid/dual graphics card BIOS is present.
> I think a single function "InitializeVGABIOSifpresent" to enable
> access to VGA/VESA BIOS functionality might actually be fairly easy to
> implement.
> Furthermore, there is no need at all to access hardware specific stuff
> like you mentioned, as the necessary functionality is completely
> covered by the int 10h interface.
>
> Imho it could be worth to allocate a small part of the sponsoring
> budget to put a bounty to motivate people (including possibly me) to
> implement these improvements regarding suspend/resume and enhanced sc
> and vt usability.
>
>
>
> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann <sblachmann@gmail.com>
> > wrote:
> >
> >> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> >> > Not without loading the xorg graphics stuff... graphics chips from the
> >> last
> >> > 15 or 20 years have lots of chip specific state that only the graphics
> >> > stuff knows about... IIRC, it only knows about it because it put the
> >> > graphics into a known state... it's the main reason laptops stopped
> >> > suspending in the early 2000s... it looks to be a lot of work for a
> >> > relatively rare use case...
> >>
> >> UEFI GOP seems to have the necessary functionalities
> >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work
> >> required would be limited (restore mode and redraw screen from
> >> buffer).
> >>
> >
> > UEFI GOP isn't available after we start the kernel, so this is a
> > non-starter.
> > It works great in the boot loader, but not so good after we boot. It
> could
> > work
> > for S3 sleep to disk where we actually reboot to restore the machine
> state,
> > but we don't have sleep to disk today :(
> >
> >
> >> With non-UEFI or old UGA UEFI implementations possibly one could use
> >> the dual BIOS´ CSM part. Just call the CSM BIOS init to set up GPU and
> >> the int 10h interface, and then set previously used mode+redraw.
> >> BTW, doing that also could both enable vt(4) to change
> >> modes/resolutions and using sc on UEFI computers.
> >>
> >
> > Ah, if only things were really that simple...  I tried variations on that
> > hack years ago when suspending broke due to video. And it
> > works for some machines, but not others, was the quick assessment
> > I made. And the INT xx interface is unavailable on amd64 after we
> > enter long mode (I tried this out on my then-current FreeBSD laptop
> > which was 32 bit only, so 15 years ago?).
> >
> > Warner
> >
> >
> >> But I think you are right, there are probably not too many users who
> >> would make use of that.
> >>
> >>
> >> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachmann@gmail.com>
> >> > wrote:
> >> >
> >> >> Implementing S3 suspend/resume was a sponsored project itself.
> >> >> However, it still does only work when at xorg graphics mode, which
> >> >> already was topic in this thread.
> >> >> When using it from console, no matter sc or vt, it still hangs with
> >> >> dark screen and unresponsive keyboard.
> >> >> Could finishing the suspend/resume work be sponsored, so that it also
> >> >> works on console-only computers?
> >> >>
> >> >
> >> > Not without loading the xorg graphics stuff... graphics chips from the
> >> last
> >> > 15 or 20 years have lots of chip specific state that only the graphics
> >> > stuff knows about... IIRC, it only knows about it because it put the
> >> > graphics into a known state... it's the main reason laptops stopped
> >> > suspending in the early 2000s... it looks to be a lot of work for a
> >> > relatively rare use case...
> >> >
> >> > Warner
> >> >
> >> >
> >> >> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
> >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm@FreeBSD.org>
> >> >> > wrote:
> >> >> >
> >> >> >> On Thu, 2021-12-30 at 08:05, Özkan KIRIK <ozkan.kirik@gmail.com>
> >> >> >> wrote:
> >> >> >>> I've ideas about enhancing the routing architecture. Is it
> >> >> >>> possible
> >> >> >>> to
> >> >> >>> add to wiki?
> >> >> >
> >> >> >> Certainly.  Please do.
> >> >> >
> >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >
>
>