Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Doug Bissett

Pages: 1 ... 70 71 [72] 73 74 ... 107
1066
Quote
On this case I'm only suggesting to have like two of each one, so it can be very pinpointed and limited to specific devices that are available with a well define chipset.

I doubt if that would work. It seems that the same device gets different names, and PCI IDs, depending on where it is sold. So you can say that devices X, and Y, are "supported", but if it is sold as device Z, in your region, what do you do? The other big problem, is that motherboards come with devices, that the user has no choice about (in most cases). Recently, I got an Asus A88XM-A motherboard. The specs looked like it might work, but the wired NIC is a "Found Realtek NIC at bus 3:0:0: 10EC:8168 version 39 (RTL8168g/8111g)". Multimac loads, and it works at 100 Mbs (should be 1 Gbs) for a short period, then it just stops. As the information shows, it is version 39 of the SAME device, and it obviously requires something different.

When I got my Lenovo ThinkPad L530, I had a choice of three WiFi adapters. I don't remember the details, but one was a Realtek (called a "Lenovo device" so it could easily be replaced by something else entirely, with no way for the user to get it changed), and the other two were Intel. I chose the more basic Intel device, hoping that GENMAC would support it until Multimac did. In fact GENMAC does operate the device, BUT, there is no way to turn the radio on (apparently, the more advanced Intel has the same problem), so it works exactly like a wired NIC, with no cable connected. I expect that Multimac will support it, when the driver is done, but I can only hope, until I see it work. Actually, there is another choice. I could get a device that is currently supported by GENMAC, and modify the BIOS (invalidating the warranty) so that it will allow it to be used. Even then, I am not confident that I would be able to get the radio turned on, since that now seems to be a function of ACPI.

Quote
Even with a disclaimer that says "AS IS" without warranty that it will work

That is a required statement, for anything that gets done. Without it, the programmer is wide open to law suits, and the problem may not even be caused by the program. They may need to prove (at great expense) that it wasn't their fault, and that may be impossible. Unfortunately, such a statement makes any indication that something will work, useless, because it may not work.

1067
I agree with Dave. In theory, it is a good idea, but when you get down to the details, it becomes a nightmare to try to support it. You can find the same device in different parts of the world, with different drivers. You can find the same driver used in different devices. You will find that the "same" device will suddenly change the chip, and will use a different driver. Laptops don't always have the same hardware, even though they are the same brand and model.

Arcae Noae, as with Mensys, cannot say that device X will always work, because the manufacturers don't always make them the same. Some manufacturers (Intel, and Broadcom, for instance) seem to be pretty consistent, in that the same driver supports a number of devices, but if the specific device isn't in the supported list, the driver may refuse to load. Other manufacturers (Realtek) tend to need different drivers for each device that they manufacture, even though they have the same description.

Then, you run into the problem where some manufacturer (Lenovo, for instance), says that device X, and device Y can be used in one of their laptops. There is no good reason why device Z won't work, but you need to modify the BIOS (which invalidates the warranty) to make the BIOS accept device Z.

There is no good answer, and Linux has the same problems, but they have enough programmers to work through it. If Arca Noae can find a good way to port drivers, the problem should lessen, but it will probably never be solved completely.

Arca Noae could, and probably should, post the exact devices that they work with, but that would always be an incomplete list, and it could be wrong if the manufacturer changes something.

1068
General Discussion / Re: OS4 kernel and associated files
« on: May 26, 2015, 04:07:05 am »
Quote
This memory hole problem is unexpected. I thought I had this same hardware working without a memory hole. Perhaps it can be eliminated in BIOS.

Try QSINIT. It has worked for me, and you can use the RAMDISK that uses memory above the  GB mark (if you have any).

1069
Quote
I disagreed with that. WarpIn is freeze and Paul Ratcliffe only fix bugs from time to time but he does not add new functionality.
Try contacting him asking for new features and let us know what he replies.

I didn't say that WarpIn is frozen. Paul will do new features, if the person asking can tell him exactly how to do it (in which case they should probably just do it, and present Paul with the finished product). If they can't, they will take a lot of abuse from Paul. It has happened more than once to me, and I have seen him do the same to others. I do know that Alex T. is working with him to get the Arca Noae package manager to work with WarpIn, but I haven't seen any results from that, yet.

Quote
Does Warpin need any new features, after all it does what it sets out to do - install a program.  It is not a system maintenance tool and was never intended as such.  RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.

I don't entirely agree with that. WarpIn could easily be used as a maintenance tool. In fact Chuck M. did eventually start to use it with eCSMT, before he quit doing that. ECSMT was supposed to be a system maintenance tool, but eCS became pretty static, and eCSMT seems to be abandoned. RPM/YUM is also just a package installer, but it adds a few features that could be handy, if they would work consistently. Consistency has improved a lot, since Arca Noae rattled the chain, while trying to get a package manager to work with YUM, but I still don't have a good feeling about YUM.

Quote
That leaves the home/hobby user who, generally, knows what they are doing with their systems.

Unfortunately, that is not entirely true. My guess would be that less than 10% of those users actually know what they are doing with their systems. The other 90% are the ones who are targeted by things like WarpIn, and YUM. The idea is to make it easy for those who don't know, to be able to get it right (or close enough to work).

Quote
Not sure why you're suggesting Martin work on CUPS? Last I checked, he has no involvement, other than maybe testing some components...

Well, testing, and feedback, was what I meant. Better that than wasting countless hours chasing something that doesn't need to be fixed, is likely to cause problems, and isn't important anyway.

Quote
I just want to RPM/YUM to officially support "Moving unixroot tree away from the root directory" : )  , which is not going to happen according to bww

I still need to ask WHY? There is no point in doing that, and it isn't going to improve the way that OS/2 works, even if doing it doesn't cause problems. I will agree that RPM/YUM really should put things where OS/2 has always put them, but that makes the whole project much more difficult, and those who are doing it seem to want to simplify the whole thing so they don't need to do as much work. I can't blame them for that, but surely they could have found a better way.

Quote
What I would like to see, is a 64 bit OS/2 or, at least, better operation on multi core 64 bit processors (maybe something for the 4OS guys to think about).

I haven't seen any problems with multi core processors (up to 4 cores). A 64 bit OS/2 is one of those impossible dreams. Nobody, on earth, knows enough about the kernel to be able to do it. The best that might be possible, would be to drop in a 64 bit *NIX kernel, and tweak it to work with the rest of OS/2 (which also needs major updates to work in 64 bit mode). I am sure that the OS/4 guys think about it every day, but they seem to be circling hard, just trying to figure out what the kernel actually does.

I think there is some room to improve memory allocation, IF they can figure out how that works. I also think there is room to expand on what QSINIT does with memory above the 4 GB mark, and make that available to programs, outside of the normal OS/2 memory allocation scheme. In fact, the only time I ever see my own systems use more than 2 GB of memory, is when I start up virtual machines that allocate the memory. So, a 64 bit OS/2 is really not necessary. What is necessary, is to find a way around the per process memory limits, and part of that problem is over use of shared memory (DLLs), which limits the amount of private memory available. If private memory could be allocated from the space above 4GB, that part would be solved (until shared memory eats up the rest).

Quote
RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.

In fact neither YUM, or WarpIn (or ZIP, or RAR, or ARJ, or...), is suitable for that sort of thing (but they can be made to work). On my own systems, I have experimented with using RSync to do system maintenance. I set up one system the way I want it, then use RSync to make the rest the same (including the FHS directory structure, if you like). You do need to account for files that might be in use, when the sync takes place (an alternate boot system solves that, if you need to go that far), and you need to account for those files that should be unique to each system (the RSync filters do that). Some planning is required, but once it is working, it is pretty easy to adapt it to new machines, new programs, etc. Updates could be done over the internet, if desired, or you can load up a USB disk drive (or stick), then do the updates from that. Of course, you need some control over the systems, so that somebody doesn't change something on you (but that is probably the case anyway). There are tools to do almost anything you want. Many of them are so complicated that users have no clue how to use them (especially those tools ported from *NIX), although once you work through the useless stuff, the rest is pretty easy (in most cases).

1070
Quote
But Doug, why don't you do a funding campaign to save/improve WarpIn?

WarpIn is still maintained by Paul Ratcliffe. Anybody can add to it, although I think that Paul wants to keep control of any additions.

Quote
The value that I see on RPM/YUM:
- You can install a lot of software with a single command line command and press "Y".  WarpIn should do that too.
- You can have a server that provides the software (like some kind of store).  WarpIn are single packages, should support that.
- You can install dependencies automatically with RPM/YUM, it even downloads it.
- WarpIn misses the "Silent install" feature.

WarpIn depends on what the package creator does. It can be expanded to do more than what WarpIn does by itself (including downloading dependencies), by adding REXX code to the installer. It would be better if some of those functions could be coded directly into WarpIn, but nobody seems to want to do it (or, they don't know how). A little imagination, and some REXX, will work wonders with WarpIn, but it is somewhat limited by other things. For instance, it appears that most of the ported DLLs don't have any BLDLEVEL information included, so the only reference that a user has, is what the YUM database contains (and that may not contain the proper information, in some cases). Using file size, and date, is not adequate, but would work in most cases. Without the build information, all one can do is guess at what version is installed.

Currently, Arca Noae is working on a front end for WarpIn, and YUM. The WarpIn part is still under development, since the YUM part has taken so long to do (trying to work around problems with YUM). Once it is completed, it should be easier for a user to keep control of their system, although it can't be any better than YUM, or WarpIn.

WarpIn definitely has a "silent install" feature. It is used with the eCS installer, but I don't see any reason to want that for any other reason (well, the Arca Noae package manager will probably use it). A "store" feature could be done, but is it really worth the effort? I think that the Arca Noae package installer will have a rudimentary "store" feature, but I haven't seen what they plan, yet. I suspect that they will just collect all (or most) of the WarpIn installers into one place, and offer them in a menu. Currently, most WarpIn installers are available at HOBBES.

1071
Quote
It is too bad that bww does not consider this something to be improved on RPM/YUM.

BWW doesn't write the code. All they do is port it from *NIX (and many *NIX distros are abandoning YUM simply because it doesn't work very well). *NIX specifies that /usr is in the root, so that is where it ends up. *NIX also knows nothing about drive letters, so it is necessary to have all of the RPM/YUM (also *NIX ported programs) parts on the same drive as /usr. To change that means that somebody (not necessarily BWW) would need to find all of the places where things would need to change, and change them. That, in itself, would introduce a whole new area for bugs to be introduced, and it probably means that everyone who ports *NIX programs, would need to do even more work.

I think you are fighting a losing battle. If users want to use *NIX programs, it seems that we have little choice but to follow the current lead. The unfortunate part, IMO, is that there are very few *NIX programs that are really worth porting, and more effort on those few programs would likely have better results, than trying to port every program that *NIX has produced, but everybody has different needs. It is also unfortunate, that it is seen to be easier to port programs, than to write new ones from scratch. Years ago, OS/2 produced many original programs that were far superior to those on other platforms, and they got ported to other platforms. Today, the only one left is PMView. PMMail is still being developed (although very slowly) for OS/2, but VOICE is not allowed to port it to other platforms (that was part of the purchase agreement). The main "problem" with PMMail is that the main developer has not had the time to work on it, for many months, and nobody else has stepped up to help out (it is all volunteer, and any proceeds from the program go toward keeping the VOICE web site running, and to support other OS/2 projects). The battle today seems to be to keep things as simple as possible, simply because we don't have the manpower to do anything else.

I will note, that it is still my opinion, that spending a little time improving WarpIn would have been far more productive that messing around with porting RPM/YUM. Unfortunately, those who know how to do such things, decided otherwise, and now we suffer the consequences.

1072
Quote
Doug, it is all over again, your "negativism" disguised as a "reality check".

I am not being "negative". It is a "reality check" simply because it is totally unnecessary to move what exists (even if what exists is totally out of step with what OS/2 has always done).

Quote
The thing is that "IT WORKS" you can move tree away from the root directory and "IT WORKS" !!!!
We don't need million of people testing it, we just need a small team for that.

Perhaps it works today. If the support people don't support what you attempt, will it work tomorrow? Putting the DLLs into \os2\DLL also works, but you are on your own if you do it. Why introduce more uncertainty t6o an already delicate setup? That just does not make sense.

Quote
Sorry guys to rant about it, but that is the way that I see it.

The way I see it, is if it works as it is, leave it alone before you cause trouble, and need to spend a lot of valuable time sorting out what went wrong. Your time, and the developers time, can be better spent testing, and fixing, things that are in need of testing and fixing.

One of my favorite sayings: "If it ain't broke, fix it 'till it is" seems to apply to your approach to "fixing" OS/2. All you are doing is introducing more way for something to fail. Why don't you spend time working on the CUPS project. CUPS 2.0 was broken (HP printers), last time I had time to mess with it, and CUPS is a very important program for OS/2. It is definitely far more important than moving a few directories around, for no good reason. YUM, SAMBA, RSync, QPDFView, USB drivers, ACPI, UniAud, and many more need more testing, and the developers need feedback (good or bad).

We just don't have the manpower to mess around with stuff that isn't important, especially when doing so may cause more problems than what we have now.

1073
Quote
If someone also agreeds with this request, please let me know.

I fail to see the point in even thinking about that. Who cares where it is, as long as it works (and it does seem to work, as long as the user cleans up the rest of the mess that is left behind when the conversion is done, and as long as YUM doesn't mess it up, which happens far too often <although it has been better recently>).   

Currently, the user has a choice to put it on the boot drive, or put it on another drive. My personal choice is to put it on another drive, and I share it between boot systems. The main advantages are that one update updates both systems, updates can be done from either system, and a new install doesn't wipe it out, it just picks up where you left off. Of course, all of that depends on the user cleaning up what gets left behind by other install methods. The main disadvantage (that I know about) happens when the host drive needs to have CHKDSK run standalone. Having a bootAble partition looks after that problem, but it can also be done using an eCS install CD.

Don't get me wrong, I am very much against the whole thing, as it exists, but it looks like we need to suck it up, and live with it, or do the work to work around it (which is proving to be very complicated).

1074
Programming / Re: Non-yum/rpm vs. ordinary (?) eCS
« on: April 26, 2015, 06:30:36 pm »
Quote
this weekend, a very kind eCS user informed me that there were a difference between standard
and yum/rpm based Warpin installers.

WarpIn is a native OS/2 (AKA eCS) programming package installer. RPM is a packaging method that YUM uses to install, and track, programming packages (which also includes DLLs). RPM and YUM are ported from the *NIX world. Each has it's own advantages, and disadvantages. Some discussion can be found in the OS2world forums.

Quote
I thought that OS/2 - eCS and NT were siblings so that any DLL linking/path problems experienced
on UNIX-based systems did not happen to us ?

More, or less, true, but each method has it's own advantages, and problems. The main problem, that we have today, is that those who are porting *NIX programs to run in OS/2 don't want to spend the time to find all of the places where *NIX type DLL linking is used in the programs, and convert them to OS/2 type linking,  so they have decided to make a *NIX type of directory structure, with specific rules, to use with OS/2. That is essentially not compatible with the original OS/2 linking methods, but it does work, if you follow their rules. The result is what is known as "DLL HELL", if you break even one of the rules that the *NIX setup requires.

*NIX assumes that there is only ONE place, where all DLLs reside. By extension, that means that it is not possible to have more than one copy of any specific file name. That means that a user doesn't have to worry about down level, or duplicate, DLLs. One of the ways that *NIX updates such things, is by using RPM/YUM (although it seems that most distributions are moving on to something better). If you install RPM/YUM when you first install eCS, and NEVER use anything else to update, or install, anything, you will probably not have too much trouble. However, RPM/YUM does not install everything, so the user needs to use another method to install things. IF the user knows about the *NIX directory structure, and correctly uses that, they are likely to avoid most of the potential problems. Most OS/2 users have no idea what that is all about, so they almost always mess it up, and that will, eventually, cause trouble, especially if RPM/YUM is installed after the fact.

Some things that I have learned while testing the Arca Noae package installer (currently known as Yumie):

RPM and YUM work okay, when they work. It has been obvious that they do not always work properly. Yumie is only as good as YUM, and fixing problems with YUM can be a PITA.

An average user had better stick to the RPM release repository, or they are likely to have serious problems that can take some effort to figure out, and fix.

One "problem" with the release repository is that it can take MONTHS for new things to show up (also true of the experimental repository, but it is usually closer to being current).

Yumie is supposed to handle WarpIn packages, as well as RPM packages. So far, the WarpIn part is in early development. Far too much time has been required to try to work around YUM problems, so it hasn't been done yet.

The old RPM/YUM, installed by WarpIn, has a serious problem. Apparently, most users (including me), assumed that one should always use the YUM console to do updates. WRONG!. That uses a temporary sub set of YUM to get the current YUM package installed. The instructions do indicate that you can uninstall the WarpIn package, but it is not clear that you really should uninstall it (which also removes the YUM console). If you (correctly) use a normal command line to run YUM, it will work as well as it ever does. If you use the YUM console window, it will continue to use the old, temporary, installation, with down level software, and that causes problems. If you installed RPM/YUM with the eCS installer, it should work properly (but seems to break often).

Some things that you can do to prepare for the future:

Make sure that there is only ONE location where you keep "system" DLLs. By "system DLLs", i mean those that are used by more than one program (LIBC, GCC, and many others). This is complicated because eCS has added a new DLL directory where it keeps those things. When you add RPM/YUM, it makes another one, and takes no steps to remove duplicate (usually down level) DLLs from the old locations. Now, you have a problem if the wrong DLL gets used first, for any reason. The program that loads it will probably work, but if you then try to load a program that requires a later level, it isn't going to work (more likely, only one feature of the program won't work). If the later level DLL gets loaded first, both programs will work.

Look on your system for duplicate DLLs that may possibly get loaded. They don't necessarily need to be in LIBPATH. REMOVE them. Some programs were (incorrectly) packaged with DLLs, as a convenience to the user when they were distributed, and those do not get updated if they are not in the proper place. PTHREAD and MMAP are common.

Some users thought they were smart by moving "system" DLLs into "the only program that uses it" directory (Firefox, for instance). Now they installed a new program that uses one of those DLLs, and it won't work, so they finally figure out that it needs a DLL that is in Firefox. Their answer was to add Firefox to the LIBPATH. Then, they wonder why installing a new Firefox wiped out the DLL that wasn't supposed to be there in the first place.

Anyway, users should track those things down, and get rid of them. The complication is, that programs also use their own DLLs, which SHOULD be in the specific programs directory (and NOT in the single location used by "system" DLLs, although that should work okay).

You should also be aware, that QT programs store the location of the DLLs (and other things) in %HOME%\.config\Trolltech.ini. If anything in that file gets changed, you need to delete the file (it will be recreated). That is a common cause of QPDFView failing to find the PDF, DJVU, or PS, DLLs, even though they are where they should be found.

So, welcome to DLL HELL.

1075
General Discussion / Re: Yum issue
« on: April 17, 2015, 05:40:47 pm »
Quote
I put the path after the ;.; so it would not override a dll in the current directory.

That is probably a mistake. If you have an old copy of a DLL in a program directory, and you happen to start that program first, you will load the old DLL. That program will probably work fine. Now, if you start another program that requires a newer version of that DLL, it might not work because the older version is already loaded. That can get really confusing because if you start the program that requires the newer DLL first, both programs will work because the newer DLL will be loaded.

It is important to eliminate ALL down level duplicate DLLs, everywhere on your system, if there is any possibility that they will be used by something. When you use RPM/YUM, it is ASSUMED that the ONLY copy will be the one that YUM controls. Therefore, the .; entry should be second, to reduce the possibility of using the wrong DLL (it is still not impossible). The .; entry should only be used for program specific DLLs, and those should only be in the program directory, and there should be no duplicates, so it shouldn't matter where the .; entry is located in the LIBPATH statement, other than to reduce the time required to find it.

Note that some programmers have INCORRECTLY included DLLs in their packages, thinking that they are helping the user. The end result is duplicate DLLs, at different levels, and much confusion. The most common seem to be PTHREAD.DLL, and MMAP.DLL, but there are others.

I will also mention that QT programs store information about DLLs (and other things) in %HOME%\.config\Trolltech.ini. If you move a program, or a DLL, QT programs can quit working because the entry is now wrong. The fix is to delete the %HOME%\.config\Trolltech.ini file. It will be rebuilt. That "feature" has caused problems, for me, more than once. I haven't done it, yet, but I am going to simply delete it at every boot, if it causes me trouble one more time. Apparently, it will cause QT programs to take a fraction of a second longer to start, but I can live with that, while the complications can be a PITA, usually at a very inconvenient time.

1076
Setup & Installation / Re: QPdfView install problem
« on: April 09, 2015, 04:45:43 pm »
I'm trying to install and run the latest qpdfview port for eCS.  I believe I have all the pre reqs in place based on the document that came with the package..  But when I try to open a PDF document with the program, it complains it is missing the plugin for "PDF" 

Does anyone know where I need to look in order to solve this question so that I can open PDF documents with the program?  I would appreciate a point in the right direction.

Most likely, you need to delete %HOME%\.config\Trolltech.ini. It will be rebuilt.

1077
Multimedia / Re: Media Servers for OS/2 ?
« on: April 02, 2015, 06:16:11 am »
Hi Doug, klipp here! How's it going? This is "off subject, sorry" but a couple of times recently you've mentioned about having sound working somewhat, in Virtualbox. When you've got some time available could you expound in a little more detail just how you accomplished that? I would like to mess with that a little.

thanks, klipp

I will do a quick summary here. If you wish to follow up, create a new thread, or join the Virtual  PC users mail list. From the messages:
Code: [Select]
To subscribe (new addresses), E-mail to: <virtualized_ecs_users-on@2rosenthals.com> and reply to the confirmation email.
Web archives are publicly available at: http://lists.2rosenthals.com

Sound works in VBox under Windows and Linux (probably also under Macs). It half works in VBox 1.6.1 OSE under OS/2. By "half" working, I mean that the virtual machine will "see" a sound card, but the sound is not passed on to the host sound system, so there is no sound. There are two virtual sound cards available. One is the old SoundBlaster 16, and the other is an AC97 (works with UniAud). Under windows host, eCS will configure either one, and it will make sounds, but I find that even under a powerful processor, the AC97 causes breaks in the sound (unusable). Using the SB16 works reasonably well. The same problem happens in WinXP guests. I really haven't tried other guests.

In the past, I got sound to work under Virtual PC 5.1 in OS/2, It has been some time since I tried that, but there is a parameter for the configuration program, that allows you to enable sound in the guest under OS/2. "TWEAKVPC" (no quotes), or something like that. There is a warning, somewhere, that doing that could cause problems because the feature is not finished. As I recall, that is probably true.

1078
Off Topic discussions / Re: April Fool's Jokes.
« on: April 02, 2015, 04:22:23 am »
OS/2 is DEAD!

April fools...

Sorry, I couldn't resist...

1079
Multimedia / Re: Media Servers for OS/2 ?
« on: April 01, 2015, 05:34:07 pm »
Quote
1) Could someone post their Mediatomb setup please or post any tips on the setup !

It has been a few years since I set up Mediatomb. I don't remember that it was difficult. Just follow the directions. There would be no point in posting my setup, because it is extremely unlikely that your setup would be anything like mine. Basically, you just tell it what files/directories to expose. There is a better set of instructions at: http://mediatomb.cc/. I use "Set Autoscan" so I don't need to mess around with Mediatomb when I add new things.

I haven't used Mediatomb very much, but it has worked well, every time I tried it (never with anything but eCS and windows).

Quote
Mediatomb sounds like a good thing, particularly if running under Java 6.

Mediatomb is a native OS/2 program (ported from somewhere else). It is not JAVA. Access is through a web browser.

1080
Quote
You're misunderstanding the difference between address space and virtual address space. Just with segments there is actually 256 segments of 4GB each available and OS/2 understands this.

That is what the hardware is capable of doing. OS/2 doesn't use it that way, and I doubt if it "knows how", or somebody would have figured it out, by now.

Quote
Of course OS/2 is old and they didn't put much work into, what at the time was considered insane memory usage but the capability is there.

In fact it is still insane memory usage. Unfortunately, there are more insane programmers around.   ;D

Quote
Probably less due to limited amount of page table entries, but that can be worked around by using 1 (4?) MB pages instead of 4KB pages

If somebody can figure out the page handling system, the problem could likely be solved. The kernel would still be limited to 3.5 GB addressing, but that 3.5 GB could be a different 3.5 GB space than the next program is using (not quite that simple, I am sure, but...). In fact, I got the impression that that is exactly what PAE addressing does. The problem is with managing it, and telling the kernel that programs can actually have overlapping addresses (in different address spaces). I think it would be much easier to simply work outside of the kernel, for private data storage, but the interface needs to be defined, and programmed. If that is done, the shared memory space can be expanded into the area vacated by the private memory. Not a "perfect" solution, but it should be possible, without trying to mess with the kernel, for somebody who understands the concept. Then, programmers would need to change their memory calls to access it that way.

Pages: 1 ... 70 71 [72] 73 74 ... 107