OSDev.org

rdos wrote:

Griwes wrote:

rdos wrote: Right. I don't implement permissions of any sort, so it cannot happen.

Oh, another in the set of "rdos Fallacies": "I don't implement a check, so permission error will never, in any environment, on any system, written by any programmer, in any times, happen". I hope you realize how retarded that is; if not, you should be able to smell an ad hominem here.

Other OSes that does have permissions need to solve the issue. I don't since I find the user/permission model lame and useless. You typically need keys and encryption to protect things, not permissions.

Griwes wrote:

Code: Select all

process foo("/foo/bar/baz.exe");
if (!foo.run())
{
     // ... how do I determine why it failed right in here? Oh, I don't, because one of yours non recoverable errors happened, and I can't even tell the user why. Too bad.
}

Too bad? You mean you want a customer at a petrol station to see a pop-up dialog saying something like "Couldn't start foo because I had no permssion to use the file" or "Couldn't start foo becase the file is corrupt". What use would the customer have for this information? I'd expect to see something like "Terminal is closed".

Your specific case is 110% irrelevant. This is a general thread, about general use OSes. Your specific case is 110% irrelevant. I want to see "Couldn't start because [...]" with a detailed description of a problem on my console after typing a command; I don't remember serving customers at a petrol station using my PC. Your specific use case is 110% irrelevant. You said that other OSes that have permissions need to solve the issue - and we are talking about those OSes, not your lame, specific case of not using permissions at all at your 110% irrelevant at these forums OS that is only used at petrol stations and never anywhere else.

rdos wrote:The point was that ACLs are part of software, so if I boot another OS that knows about the filesystem, but doesn't give a damn about ACLs, that other OS can do whatever it wants with the files. Or it could simply format the disk to get rid of the content. With encryption, you can very well delete the data, but without the key and algorithms, you cannot read protected data. Not so with ACLs.

Perhaps that's because ACLs and encryption are two different tools for two different jobs.

rdos wrote:Of course. First, the download manager will not even try to start the application if it's MD5 sum doesn't match the distributed checksum. That takes care of "file not found" and "corrupt file".

Last time I checked neither HTTP nor FTP required the server to send a checksum with a file. And a download manager should manage downloads, it's not supposed to start any program. The one starting programs is me, the user. Programs in local files that I got from somewhere, using the tools I want and not the one blessed rdos download manager.

And since it is started from boot, out of memory is not an issue, but if it is, the application starting it can query about free physical memory and other resources.

Are you talking about petrol station terminals again or what is started from boot in which context? To be clear, I'm not interested in your OS specifically.

XanClic wrote:If in doubt, you can always just kill the application which uses the most memory.
Most of the system programs should use relatively few memory, thus this should work pretty well. Alternatively, you could also have a special user (or profile or whatever) which is used to run the system applications (for Linux, this would probably be root) - applications which have been started by that user (or are running on that profile) simply aren't killed (or maybe last).

The rule of thumb is that the OOM killer always kills the wrong process first.

This is a very hard problem to solve. There is, of course, the obvious solution that you just disable overcommit, but that's not really practical.

rdos wrote:That's fair enough. I could delete your permission based data simplying by booting RDOS on your target machine, and then deleting any file I'd like to delete. Alternatively, I could use the rmpart command to remove the complete partition(s) for you.

Hahaha I guess so. I think modern BIOSes will have anti-RDOS protection.

Kevin wrote:The rule of thumb is that the OOM killer always kills the wrong process first.

You can check it here

oom_kill.c

Kevin wrote:Last time I checked neither HTTP nor FTP required the server to send a checksum with a file. And a download manager should manage downloads, it's not supposed to start any program. The one starting programs is me, the user. Programs in local files that I got from somewhere, using the tools I want and not the one blessed rdos download manager.

First, the download manager is not part of the RDOS project (it would be a nice tool to have for embedded developpers), rather is proprietary. Second, the user will never start applications in typical stand-alone embedded systems. Besides, you will have a very hard time starting anything without a keyboard.

"rdos download manager" as in your user name, not in your OS name - my point is about fitting the design of an OS (any OS, not specifically yours) only for included programs. I'm still not interested in the specific requirements for your OS (for which this may actually work), but in discussing generic concepts.

Kevin wrote:"rdos download manager" as in your user name, not in your OS name - my point is about fitting the design of an OS (any OS, not specifically yours) only for included programs. I'm still not interested in the specific requirements for your OS (for which this may actually work), but in discussing generic concepts.

You don't need to do it that way. There is a shell

It was just an example of how it could be done without a shell. Within a shell, it's pretty easy to check permissions of an executable, and the presence of the file before attempting to execute it. That would be common sense in a shell.

Throwing away the error information in libc and then telling each user of the function that they should retroactively try to reconstruct it is plain stupid.

It leads to code duplicated in each application (in the best case; in the more realistic case, they duplicate only half of it and don't check the other half of the cases), inconsistent error messages (because every application gets to choose its own wording), perhaps even cases that can't be distinguished by the caller at all, race conditions if the error condition is only temporary, and probably lots more of this kind of fun.

Kevin wrote:Throwing away the error information in libc and then telling each user of the function that they should retroactively try to reconstruct it is plain stupid.

It leads to code duplicated in each application (in the best case; in the more realistic case, they duplicate only half of it and don't check the other half of the cases), inconsistent error messages (because every application gets to choose its own wording), perhaps even cases that can't be distinguished by the caller at all, race conditions if the error condition is only temporary, and probably lots more of this kind of fun.

I know exactly what "error code inflation" leads to. When each and every device and piece of software has it's own error-reporting codes, you will have to duplicate the code for decoding error information in a huge amount of instances, and at the higher levels you also need to pair the error codes with the specific device that generated them. This is what centralized error code handling leads to.

A far better method to generate user-friendly errors is to return error strings instead. Those can directly be presented to the user, or logged to a log file. They are not device specific, and the code will still check only for success or failure.

rdos wrote:A far better method to generate user-friendly errors is to return error strings instead. Those can directly be presented to the user, or logged to a log file. They are not device specific, and the code will still check only for success or failure.

It's not far better, it is essentially the same. There is no difference between a set of error strings with cardinality N, a set of numbers with cardinality N, or the set of anything with cardinality N. All you need is a set of N distinct somethings and a mapping which gives each thing a meaning. Programmers typically use integers as machines tend to have more integral bit-patterns than possible errors and these integers can be returned by a routine or stored in a special memory location/register without extra support. There is also the advantage that any map from error codes to meaningful strings is easy to write.

An error string is fine in many cases, it's definitely more than just a bool. Having error information doesn't necessarily mean to return exactly one integer whose meaning is defined as a constant from errno.h. But it means returning something usable.

There are some cases where you want code to behave differently depending on the kind of error, and you definitely don't want them to parse error strings, but I'll agree that an error string is already enough in many instances.

Kevin wrote:An error string is fine in many cases, it's definitely more than just a bool. Having error information doesn't necessarily mean to return exactly one integer whose meaning is defined as a constant from errno.h. But it means returning something usable.

There are some cases where you want code to behave differently depending on the kind of error, and you definitely don't want them to parse error strings, but I'll agree that an error string is already enough in many instances.

The whole idea of using an error string instead of an error code is so code should never parse them or use them for anything else than logging or displaying them to the user.

In addition to that, with error strings there is no errno.h or any other include files with available error strings. This would be on purpose so programmers would not parse the error strings.

rdos wrote:The whole idea of using an error string instead of an error code is so code should never parse them or use them for anything else than logging or displaying them to the user.

So, are your functions returning a string or a pointer to a string?

bwat wrote:

rdos wrote:The whole idea of using an error string instead of an error code is so code should never parse them or use them for anything else than logging or displaying them to the user.

So, are your functions returning a string or a pointer to a string?

None. I don't use error codes / strings at all. It was just a suggestion for people that like error codes.

Just chipping my 2c in.

I agree that non-reentrant functions should be avoided in modern code, and errno does (as was originally designed) make almost everything non-reentrant, there are times when it is nearly unavoidable.

For example, fopen returns a file pointer, short of adding either a FILE** argument to it (so it can return an error code), or adding an int* argument (to recieve the error code), there has to be a second channel for error information (with a return value of NULL indicating the error). This also allows the reason for an error to be seamlessly propagated up the call chain, without forcing a calling convention on parent functions.

In short, stuff like optarg and other purely non-reentrant functions should be removed, but a thread-local errno is better than the alternatives avaliable in C, and makes life easier for the developer.

thepowersgang wrote:For example, fopen returns a file pointer, short of adding either a FILE** argument to it (so it can return an error code), or adding an int* argument (to recieve the error code), there has to be a second channel for error information (with a return value of NULL in indicating the error).

Well, in Go it is possible to return multiple values at once, which, as far as I know, is often used to return a value and an error code at the same time. You could emulate this feature in C by returning a struct with two (or more) elements, although I know that this isn't actually feasible.