Re: Call for Foundation-supported Project Ideas
- In reply to: Stefan Blachmann : "7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 05 Jan 2022 16:04:16 UTC
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 > >> >> > > >> >> > >> >> > >> > > >> > > > >