Jump to content

Talk:Operating system/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 4Archive 5Archive 6

Software interrupt?

The text A software interrupt (also known as a signal) is a notification to a process that an event has occurred.[1] Whereas a user process can send signals to other user processes and even to itself, signals are usually sent from the kernel.[1]in #Software interrupt conflicts with Interrupt#Software interrupts. External events such as expiration of time slice, IPC signals and keyboard signals from the user do not fit the definition in Interrupt#Software interrupts, nor have I seen the term applied that way in any OS. Also, there is no text describing how various operating systems handle various types of interrupts.

I propose that the introduction be replaced by the text in Interrupt#Software interrupts and that subsections be added[a] describing sample scenarios in various operating systems. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:14, 25 April 2022 (UTC)

  • I'm an avid student of how computers work. So, I welcome additional information. However, the Wikipedia rules say secondary research -- reliably sourced. Timhowardriley (talk) 04:01, 1 May 2022 (UTC)
    WP:RS says secondary sources that present the same material are preferred.; primary sources are not prohibited. If you know of secondary or tertiary sources covering the same material, please add citations in addition to or in place of the current citations. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:12, 1 May 2022 (UTC)
    I don't mean to come across as fastidious. But just to be perfectly clear, secondary research is another way of saying not primary (original) research. (I wanted to word the sentence in the positive.) Of course, secondary research may be from primary sources or secondary sources. Timhowardriley (talk) 22:08, 2 May 2022 (UTC)
  • Regarding "External events such as expiration of time slice, IPC signals and keyboard signals from the user do not fit the definition in Interrupt#Software interrupts": Quoting directly from the textbook: "Among the types of events that cause the kernel to generate a signal for a process are the following: 1) [omitted], 2) [omitted], 3) A software event occurred. For example, input became available on a file descriptor, the terminal window was resized, a timer went off, the process's CPU time limit was exceeded, or a child of this process terminated." The paragraph as written seems kosher. Timhowardriley (talk) 08:25, 1 May 2022 (UTC)
    Interrupt#Software interrupts reads A software interrupt is requested by the processor itself upon executing particular instructions or when certain conditions are met. Every software interrupt signal is associated with a particular interrupt handler.; that matches what I have seen elsewhere. The text you quoted does not claim that those events are software interrupts. That citation in no way justifies the existing text. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:12, 1 May 2022 (UTC)
    The sentence you quoted is uncited. The cited text I quoted does support the existing paragraph in the article. Timhowardriley (talk) 22:19, 2 May 2022 (UTC)

Notes

  1. ^ I'm prepared to writeup descriptions of handling program and SVC interrupts in OS/360, but not, e.g., BSD, EXEC 8, GCOS, Linux, MCP, UNIX, Windows NT.

References

  1. ^ a b Kerrisk, Michael (2010). The Linux Programming Interface. No Starch Press. p. 388. ISBN 978-1-59327-220-3.

Software interrupt? (Third Opinion)

@Chatul: I'm thinking about posting this issue to Wikipedia:Third opinion. The instructions say, "[E]ditors are requested to present a short summary of the dispute, in plain English and preferably in a new subsection below the main discussion, so that 3O volunteers may find it easier to respond to." As I am the editor who wrote the article's existing operating system#Software interrupt section, I stand by my cited sentences. Please quote from the article the sentences that are being questioned. Also, present reliably sourced alternatives. Who knows, maybe this fresh start will alone resolve the conflict. Timhowardriley (talk) 22:54, 2 May 2022 (UTC)

Additional thought: The category of an event to be a hardware interrupt or a software interrupt may be divided on a thin line. For example, another textbook seems to categorize the context switch as a hardware interrupt. I put it in the software category because the cited textbook clearly put it here. So, if another textbook has an event categorized differently than the article's category, of course I will accommodate. Timhowardriley (talk) 23:36, 2 May 2022 (UTC)

The sentence in dispute is A software interrupt (also known as a signal) is a notification to a process that an event has occurred.[1]. The dispute is on whether signals belong in the article and on whether, e.g., Supervisor Call instructions, overflow traps, belong in that section instead.
I took a look at the book you sited, and the relevant text[2] does not say that a signal is an interrupt, but only that "Signals are sometimes described as software interrupts." The text in Interrupt#Software interrupts matches what I have seen, but I've added a {{cn}} template there.
There are machines with context-switch instructions, e.g., Move Stack on the B6500. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:23, 3 May 2022 (UTC)
  1. Are you're saying the entire Software interrupt subsection should be removed from the Interrupt section because it doesn't contain the term Supervisor Call Instructions? Timhowardriley (talk) 15:13, 3 May 2022 (UTC)
    No, I'm initially saying that the text should be moved to an appropriate section because it has nothing to do with interrupts, any more than straw dummy has to do with either straw or dummies. I'm then saying that there is other information that is not present but belongs there, and giving SVC as an example. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:30, 4 May 2022 (UTC)
  2. Regarding "[Kerrisk] does not say that a signal is an interrupt, but only that 'Signals are sometimes described as software interrupts.'": Signal (IPC) is the UNIX jargon for software interrupt. Do you agree? Timhowardriley (talk) 22:03, 3 May 2022 (UTC)
    Of course I do not agree. Signal is the UNIX jargon for signal. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:35, 4 May 2022 (UTC)
  3. In Kerrisk's book, the sentence following the sentence you quoted is, "Signals are analogous to hardware interrupts in that they interrupt the normal flow of execution of a program[.]" The Interrupts section in this article says, "Interrupts cause the central processing unit (CPU) to have a control flow change away from the currently running process." Are you saying this is a contradiction? Timhowardriley (talk) 15:43, 3 May 2022 (UTC)
    Why would you imagine that I am saying that? What I am saying is that "foo is anlogous to bar" is not the same as "foo is bar". Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:38, 4 May 2022 (UTC)
  4. Are you saying, because machines have context-switch instructions, the entire Software interrupt subsection should be removed from the Interrupt section? Timhowardriley (talk) 15:43, 3 May 2022 (UTC)
    No, I was simply commenting on your For example, another textbook seems to categorize the context switch as a hardware interrupt. and clarifying that a context switch could be part of the architecture rather than an OS construct, depending on the system under discussion. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:44, 4 May 2022 (UTC)
  • In conclusion, you are claiming that the sentences in the Software interrupt subsection are bad sentences. However, you didn't present reliably sourced, alternative sentences. You didn't convey what good sentences should look like. Timhowardriley (talk) 11:25, 4 May 2022 (UTC)
    I'm saying
    1. There should be an IPC section, and information on signals belongs there, not under software interrupts
    2. The section on software interrupt should discuss the major types of synchronous interrupts, including
      1. Special instructions, e.g., INT, SVC, UUO
      2. Faults, e.g., addressing, invalid opcode, overflow
      3. Debugging and monitoring facilities, e.g., program-event recording[3] (PER)
    Good sentences should say signal when they're describing signals. I'm still trying to find an online RS that is not behind a paywall. Meanwhile, I've created Wikipedia talk:WikiProject Computer science#Definition of software interrupt. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:35, 4 May 2022 (UTC)
I have reviewed Interrupt#Software_interrupts and it looks mostly good (I'm not sure interrupts from the MMU would be considered software interrupts). Operating_system#Software_interrupt, not so good. A signal is similar to a software interrupt or potentially initiated by a software interrupt but they are not the same. As explained in Interrupt#Software_interrupts, a software interrupt occurs when software executes an instruction that specifically requests it and, as a result, the CPU invokes an ISR – in the same way a hardware signal would invoke an ISR. ~Kvng (talk) 15:05, 8 May 2022 (UTC)
Regarding "not so good": You apparently agree with the INT machine instruction paragraph. What if it's the kernel executing INT? Are you questioning the error conditions? Are you questioning the user initiated termination? Are you questioning the UNIX kill() system call? Are you questioning the pipe coordinations? Are you questioning the normally occurring events -- timeslice/context switch or timer? I'm uneasy about the timeslice/context switch, but it's clearly in the textbook as a software interrupt. Timhowardriley (talk) 19:21, 8 May 2022 (UTC)


The only problem that I see with the INT paragraph is that it conflates machine language with assembly language.The second sentence should start with something like The assembler syntax is.
Depending on how you define kernel, an instruction like INT may be allowed or prohibited in the kernel. E.g., in OS/360, an SVC is allowed in a type 2, 3 or 4 SVC routine but not in a type 1 SVC routine.
I'm questioning 'everything that is not part of the computer's architecture. The material belongs in the article, but not in the Interrupts section.
There's more than one textbook, and other textbooks[4][5] define software interrupt differently. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 9 May 2022 (UTC)
@Timhowardriley, software interrupts use much of the same CPU hardware that hardware interrupts use so it is probably not right to say that a hardware interrupt is a message to the CPU and a software interrupt is not. Time-slice context switches are not software interrupts (though the do interrupt running software), they are a core operating system feature that is sometimes triggered by a hardware interrupt (timer). The interrupt character does interrupt a software process so it can be called a software interrupt but it is not what we're talking about here. ~Kvng (talk) 23:48, 11 May 2022 (UTC)
  1. Regarding "so it is probably not right to say that a hardware interrupt is a message to the CPU and a software interrupt is not.": The sentences in the article you are referring to are paraphrases from two textbooks. I added the quotes from the textbooks in the citations with this edit. Do you agree with the paraphrasing? Timhowardriley (talk) 01:17, 12 May 2022 (UTC)
  2. Regarding "Time-slice context switches are not software interrupts (though the do interrupt running software)": I used to also think so too. Then I discovered the alarm signal. In Unix-like OSs, SIGALRM sets the timer for when SIGPROF is sent to perform a context switch. Kerrisk writes on page 480, "ITIMER_PROF: Create a profiling timer. A profiling timer counts in process time (i.e., the sum of both user-mode and kernel-mode CPU time). When the timer expires, a SIGPROF signal is generated for the process." If you still don't agree that a time-slice is a software interrupt, then I'll move time-slices to outside of software interrupt. Timhowardriley (talk) 01:17, 12 May 2022 (UTC)
    Followup: I did a fresh look at Kerrisk's book, The Linux Programming Interface, and added the quote to the citation here. I'm now very convinced that time-slices are software interrupts. Timhowardriley (talk) 01:34, 12 May 2022 (UTC)
I added software ISR execution to the article and removed a sentence about messages. Does it read better, now? Timhowardriley (talk) 22:06, 8 May 2022 (UTC)
In all my research, a theme has formed: interrupts are signals -- signals either to the CPU or to a process. Even in the hardware context, Abraham Silberschatz writes in Operating System Concepts (1994), "Hardware may trigger an interrupt at any time by sending a signal to the CPU, usually by way of the system bus." Timhowardriley (talk) 22:06, 8 May 2022 (UTC)
That text is using signal in the generic English sense, not the term of art signal for Interprocess communication. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 9 May 2022 (UTC)

@Kvng: Timhowardriley moved part of the discussion to #Does a signal cause a context switch?. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:27, 11 May 2022 (UTC)

RS for SYSENTER

There is a footnote mentioning SYSENTER that cites the URL https://wiki.osdev.org/SYSENTER, which looks like a good source for details; I have two concerns:

  1. Does it satisfy RS?
  2. Should it be changed from a raw URL to a full citation?

--Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:23, 13 May 2022 (UTC)

  1. Regarding its reliability: Yes. It says, "The SYSENTER/SYSEXIT instructions (and equivalent SYSCALL/SYSRET on AMD) enable fast entry to the kernel, avoiding interrupt overhead." This seems correct and is consistent with other material on SYSENTER. Timhowardriley (talk) 15:53, 13 May 2022 (UTC)
    That's the right answer to the wrong question. I'm not asking whether the footnote is correct and relevant, I'm asking whether the cited web pages is a reliable source as defined by Wikipedia in WP:RS, specifically, "Articles should be based on reliable, independent, published sources with a reputation for fact-checking and accuracy.". I have no idea what the reputation of that web site is, and I don't want to bother converting it to a full citation if somebody else is going to remove it as not RS. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:42, 13 May 2022 (UTC)
    Do you agree with the assertion that SYSENTER is an assembly instruction to avoid interrupt overhead? Or do you think it's a dubious assertion? Timhowardriley (talk) 03:54, 14 May 2022 (UTC)
  2. Regarding should it be changed to a full citation? Sure. Timhowardriley (talk) 15:53, 13 May 2022 (UTC)
That's user generated content. It's not a reliable source. MrOllie (talk) 11:30, 16 May 2022 (UTC)

Does a signal cause a context switch?

[This thread was moved from above so it will be in its own section.] Timhowardriley (talk) 10:12, 10 May 2022 (UTC)

Followup: Do you agree that a signal causes a change from the currently running process? Timhowardriley (talk) 19:28, 8 May 2022 (UTC)

That depends on what you mean by signal. An interrupt need not cause a context switch. An IPC signal need not cause a context switch. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 9 May 2022 (UTC)
Okay, this is the root of the problem. I have yet see in text that an interrupt may occur without a context switch. Also, I have yet to see in text that an IPC signal may occur without a context switch. Timhowardriley (talk) 17:26, 9 May 2022 (UTC)
The citation that you gave[6] does not the reference to a context switch.
An SVC interrupt in, e.g., OS/360, MVS, does not in general change the context. A SIGILL signal does not switch processes. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:04, 9 May 2022 (UTC)
I respectfully disagree. Tannenbaum clearly says on page 308, "Like the trap, the interrupt stops the running program and transfers control to an interrupt handler[.]" This is a context switch. I can't comment about the SVC interrupt because I have no reliable text to reference. However, I do know that OS/360 is retired. I will believe SIGKILL does a context switch until I see text saying it doesn't. Timhowardriley (talk) 03:09, 10 May 2022 (UTC)
Whoops! I read "SIGKILL" when you wrote "SIGILL". SIGILL is the malformed (illegal) machine instruction signal. It is intuitively correct to assume that a process with an illegal instruction will be switched out and aborted. Timhowardriley (talk) 10:12, 10 May 2022 (UTC)
Regarding a Supervisor Call (SVC) interrupt in MVS: Like my lack of comment on OS/360, I have no reliable source to reference. However, the burden is upon you to provide the reliable source for your assertions. If you have a reliable source that talks about MVS servicing an interrupt without peforming a context switch, then the article will benefit from your edits. Timhowardriley (talk) 10:12, 10 May 2022 (UTC)
Generally speaking, interrupts (AKA signals) consume many CPU cycles. Moreover, advancements in hardware have made what used to be an interrupt to no longer need to perform a context switch. For example, new processors support the SYSENTER assembly instruction. See https://wiki.osdev.org/SYSENTER . However, I surmise that SYSENTER is executed for only a subset of system calls. For example, getting the process ID of a parent process is a system call that currently performs an unnecessary context switch. For a parent process ID request, I surmise that system programmers are working to take advantage of SYSENTER and skip the context switch. Anyway, if you come across a reliable source describing SYSENTER, then the article would benefit from your edits. Timhowardriley (talk) 10:12, 10 May 2022 (UTC)
The first step should be splitting the text into separate sections for generic text and text specific to particular operating systems. As part of that, I would include references[7][8][9] for a lot more than just interrupt handling. Also, if you really want me to provide sources then stop removing the sources that I have provided. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:52, 10 May 2022 (UTC)
Regarding your references: What claim are you sourcing? What page supports your claim? Timhowardriley (talk) 16:11, 10 May 2022 (UTC)
Regarding "stop removing the sources that I have provided": What edits are you referring to? Timhowardriley (talk) 16:11, 10 May 2022 (UTC)
Regarding "MVS, does not in general change the context": Is it because of this claim that you reverted my edit here? As requested above, please support this claim with a reliable source, including the page number. Timhowardriley (talk) 16:18, 10 May 2022 (UTC)
The Wikipedia article context switch says, "A context switch can also occur as the result of an interrupt[.]" Timhowardriley (talk) 20:03, 10 May 2022 (UTC)
The key word is can; it doers not say that an interrupt always causes a context switch. In fact, the same articles also says When the system transitions between user mode and kernel mode, a context switch is not necessary; a mode transition is not by itself a context switch.. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:32, 10 May 2022 (UTC)
@Chatul:: So you agree that an interrupt can/may/might/willsometimes cause a context switch. Right? Timhowardriley (talk) 06:38, 12 May 2022 (UTC)
More precisely, I agree that an interrupt service routine can cause a context switch in at least three cases:
  1. The kernel runs in a special context
  2. The ISR imposes a delay on the current thread or process, e.g., a P operation on a busy semaphore.
  3. The ISR makes a higher priority thread/process eligible to run
I don't agree that the interrupt itself causes a context switch. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:48, 12 May 2022 (UTC)
As Chatul says, an IPC signal doesn't necessarily cause a context switch. It depends on how they're implemented. IIRC when a process sends a signal to itself via the raise() call it is unlikely there will be a context switch, for example. MrOllie (talk) 11:39, 16 May 2022 (UTC)

@Timhowardriley: I added a {{disputed}} tag, which User:Timhowardriley removed with the claim "Reverted edit b/c the tagged sentence correctly paraphrases the source text. The next sentence references context switch.". Actually, the next sentence does not mention context, but only state, e.g., registers. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:43, 11 May 2022 (UTC)

Your first tag bomb was a swing and a miss. Both authors are referring to context switches for interrupts. Please stop your disruptive editing. Timhowardriley (talk) 18:27, 11 May 2022 (UTC)
This is what you call civil discourse? You are the one engaging ion disruptive editing. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:48, 12 May 2022 (UTC)

References

  1. ^ Kerrisk, Michael (2010). The Linux Programming Interface. No Starch Press. p. 388. ISBN 978-1-59327-220-3.
  2. ^ Kerrisk, Michael (2010). "20.1 Concepts and Overview" (PDF). The Linux Programming Interface - A Linux and UNIX System Programming Handbook (PDF). No Starch Press. p. 388. ISBN 978-1-59327-220-3. Retrieved April 3, 2022. A signal is a notification to a process that an event has occurred. Signals are sometimes described as software interrupts.
  3. ^ "Program-Event recording" (PDF). z/Architecture Principles of Operation (PDF) (Thirteenth ed.). IBM. September 2019. p. 4-26-4-46. SA22-7832-12. Retrieved May 4, 2022.
  4. ^ a b Hyde, Randall (1996). "Chapter Seventeen: Interrupts, Traps and Exceptions (Part 1)". The Art Of Assembly Language Programming. No Starch Press. Retrieved 22 December 2021. The concept of an interrupt is something that has expanded in scope over the years. The 80x86 family has only added to the confusion surrounding interrupts by introducing the int (software interrupt) instruction. Indeed different manufacturers have used terms like exceptions faults aborts traps and interrupts to describe the phenomena this chapter discusses. Unfortunately there is no clear consensus as to the exact meaning of these terms. Different authors adopt different terms to their own use.
  5. ^ "Many texts refer to traps as software interrupts."[4]
  6. ^ Tanenbaum, Andrew S. (1990). Structured Computer Organization, Third Edition. Prentice Hall. p. 308. ISBN 978-0-13-854662-5.
  7. ^ OS/VS2 I/O Supervisor Logic (Sixth ed.), IBM, December 1978, SY26-3823-5; with OS/VS2 MVS Data Facility/Device Support Release 1 Enhancements Program No. 5740-AM7 (First ed.), IBM, December 19, 1980, LD23-0232-0;, TNL, IBM, December 30, 1981, LN28-4994 and TNL, IBM, October 25, 1979, SN28-44683.
  8. ^ IBM System/360 Operating System - Fixed-Task Supervisor - Program Number 360S-CI-505 (PDF) (Third ed.). February 1967. Y28-6612-2. {{cite book}}: |work= ignored (help)
  9. ^ IBM System/360 Operating System - MVT Supervisor (PDF) (Eighth ed.). May 1973. GY28-6659-7. {{cite book}}: |work= ignored (help)

Unethically misquoting a textbook

@Chatul: Abraham Silberschatz's textbook Operating System Concepts (1994) was misquoted with this edit. The Wikipedia editor moved a sentence from the article into page 105 of the textbook. Page 105 does not say, "An interrupt service routine may cause the central processing unit (CPU) to have a context switch." This is highly unethical. Please move the sentence from the citation quote back to the article. Timhowardriley (talk) 13:39, 13 May 2022 (UTC)

Please stop the insane accusations and enter into a civil discussion. I did nothing unethical, nor did I misquote anything. Unlike you, I'm not perfect, and failed to notice that the references belonged the middle of the sentence rather than the end --Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:48, 13 May 2022 (UTC)
I'm sorry to have categorized your edit as unethical, if you are unaware of the result. Before your edit, Operating Systems Concepts (page 105) said, "Switching the CPU to another process requires saving the state of the old process and loading the saved state for the new process. This task is known as a context switch." After your edit, the article erroneously claims page 105 says, "Switching the CPU to another process requires saving the state of the old process and loading the saved state for the new process. An interrupt service routine may cause the central processing unit (CPU) to have a context switch." Please fix this. Timhowardriley (talk) 21:03, 13 May 2022 (UTC)
Please check my latest edit to verify that I correctly disentangled inline text from text quoted in the citation. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:48, 30 May 2022 (UTC)

Removal of IBSYS/IBJOB

@Maury Markowitz: An edit by Maury Markowitz on June 17 removed mention of IBM's IBSYS/IBJOB.[1][2] I believe that, due to their influence on GECOS and OS/360, IBSYS/IBJOB and the related PR155[3] were important milestones and should be mentioned. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:16, 17 June 2022 (UTC)

I don't recall doing this, it must have been a fat finger. Maury Markowitz (talk) 21:47, 17 June 2022 (UTC)

References

  1. ^ IBM 7090/7094 IBSYS Operating System - Version 13 - System Monitor (IBSYS) (PDF) (Eighth ed.). IBM. December 30, 1966. C28-6248-7. Retrieved June 17, 2022. {{cite book}}: |work= ignored (help)
  2. ^ IBM 7090/7094 IBSYS Operating System - Version 13 - IBJOB Processor (PDF) (Second ed.). IBM. July 1965. C28-6389-1. Retrieved June 17, 2022. {{cite book}}: |work= ignored (help)
  3. ^ IBM 1410/7010 Operating System (1410-PR-155) - Basic Concepts (PDF) (Fourth ed.). IBM. November 1965. C28-0318-3. Retrieved June 17, 2022. {{cite book}}: |work= ignored (help)

RS for influence of IBSYS/IBJOB on GCOS (née GECOS)?

Does anybody have a WP:RS for the influence of IBM IBSYS/IBJOB on GECOS? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:32, 18 December 2022 (UTC)

"Commodity operating systems" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Commodity operating systems and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2023 January 24 § Commodity operating systems until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Steel1943 (talk) 16:36, 24 January 2023 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Operating_system/Archive_6&oldid=1204236955"